Direkt zum Hauptbereich

Stop the software / car analogy

I can understand that making analogies is a very powerful form of explaining a hard concept, but you should be aware of the demons you might be unleashing. 

I like analogies, as much as anyone. I do the Einstein-Train-Thing to convince my self that I understand relativity like the next man. But everybody is careful talking about relativity and nobody would walk outside the framing without considering it very carefully.

Software on the other hand is not so respected, and I ask you: does the next man really get it?

Everybody can relate to cars, right? So that is a good reason to use the analogy, you would think, but here is where I have to disagree:

Thinking you know about the domain, sells, production lines, marketing, resourcing, electronics, hydraulics and all the engineering that has been put into the car is the first mistake. The second mistake is assuming other people do (unless they work for BMW or something like that). 

You think you are making the software concepts simpler, just by equaling them to something people can relate, but you (if you are a developer) understand the software as an engineer would understand a car (maybe not even all cars, just some models). So you see the way things have to be mapped for your analogy to hold, but by making others think they can too, there is very much harm done. 

People automatically will start solving problems in the car domain, not worrying of the other side of the equation. I see it all the time, they discuss for hours (true story) about the wheels, and colors and sport edition vs. luxury set-up implying there is some high cognitive back-port to the software domain that you originally were talking about. Concepts get all weird and people get very creative and try to illustrate their concepts talking about paper cars, or invisible cars that only exist for one ride (true story again). 

That is simply wrong. Try to elaborate your concepts without the use of analogies, unless you are absolutely positive that  you can defend your framing.

There are of course some examples that work but they work on the bad side of making analogies, i.e. making an obviously far-fetch connection, like: "you buy a car, and some little writing in the ignition says that by turning the key you agree to drive only to a Toyota authorized cinema". This would illustrate very good some software licensing agreements in real life. 

But generally speaking, there are more reasons why software is not like cars. Here are my top 5:
  1. The user experience of software and cars is not the same. You don't drive software. A computer drives it for you.
  2. While costs of developing might be similar in car and software domains, the cost of production of software if mostly 0.
  3. People that reverse-engineer and understand a car, still can not make one.
  4. You can't paint your software blue and sell it as blue-edition.
  5. Try rebooting a crashed car.
Think about this the next time you try to explain your software.

Kommentare

Beliebte Posts aus diesem Blog

JUnit testing services and clients with javax.xml.ws.Endpoint

Following situation: you have written some generic stub to use in your projects that creates a client for a service. Your client is smart and does some magic for connections (proxy, cache or other kind of magic). Or maybe you just have written a service for that matter. Anyway, you now want to test it. Unit testing the functionality of your methods is a must. But you still want to reach 100% coverage and need to test the service as it would run in real life.
Then you can use the javax.xml.ws.Endpoint class.
If you prefer figuring it out yourself, you can find the code (as a project for netbeans) --here--
To follow the code examples as html click  --here--

So here is how you do it:

If you've coded nothing fancy, then you probably have a class like this:



This is a generic client for opening connections to services. It gives you back a port of the type of your service where you can call your operation as a method of the port. It is very convenient if you have to do some nasty network-conne…

12 steps for software development

We admitted we were powerless over planing—that our time had become unmanageable. Came to believe that a Power greater than ourselves could restore us to sanity. Made a decision to turn our will and our lives over to the care of The Team. Made a searching and fearless moral inventory of ourselves. Admitted to The Team, and to managers the exact nature of our wrongs. Were entirely ready to have The Team remove all these defects of character. Humbly asked The Team to remove our shortcomings. Made a list of all projects we had harmed, and became willing to fix them all. Made direct bug fixes to such projects wherever possible, except when to do so would injure them or others. Continued to take personal inventory and when we were wrong promptly admitted it. Sought through code review and automation to improve our conscious contact with The Team, committing only tested features. Having had a spiritual awakening as the result of these steps, we tried to carry this message to other developer…

male death rates and hot pants