Friday, October 23, 2009

Software Development is like buying a car, You never get what you wanted

I like the analogy between software development and buying a car. There is a car you would like to have, there is a car you can have, and there is the car you get. Unless you are rich, the "car you like" is never the car you "can pay". And most of the time the "car you get" is not the "car you can have". Why does it happens the same in software development? There is an application the users would like to get, there is an application you could potentially build, and there is an application you end with.


Imagine when you ask anybody, which type of car they like, without any budget restriction. They will be describing the car they would like to have, because they do not know the cost of it, they don't have to think about anything else other than the features they want, "red, wicked fast, leather seats, chick magnet, starts with an F and ends with errari".




You realize that is impossible, so you make some suggestions on what is feasible with the resources you have. Then you show them what they could have, "it's blue, not so fast, does not scare chicks, starts with a T and ends with oyota".


Then you start looking deeper about the car and what you can get, things that are not needed anymore, the other things are needed like a big cargo area, it should also be very light, doors are not critical, the budget gets smaller and smaller as you spend money and time going over the bigger cargo area and low weight constraints, so you end up with a Citroën Méhari.


Once you appear with the car at the front door, they will complain about it, it's not as fast as they expected, it doesn't heat the seats, it doesn't have air conditioner, etc. And even when you actually do not like the car, because it's not what you expected either, you have to start explaining them why. "Well the budget was low and we had to get the car very fast, and we spend a lot of time and money going over the changes you wanted, like the cargo area and the weight constraints, so this is what we could come up with."


Not only you have to deal with that, you also have to deal with the mechanics behind the car. Your good mechanic will complain, because it's not fuel injection, which is the last trend in cars, and the guru mechanic who created the initial piece of the warp core is gone for a better paycheck to a company building "The Enterprise". Your internship mechanic was not be able to understand the warp core and broke it, so he replaced it with a 2 cylinder engine.

Have you seen this happening in your projects?
The business team just expects results, without committing to the project because they are too busy making money. They don't even care how you do things as long as they are done, and complain to the CIO when anything is not what they expected.
Managers get lost with endless list of development tasks, and spent most of their time updating project plans after every meeting with the business. They also create tasks for everything the business team ask for and put them with the highest priority.
The development team is creating the warp core because it's a technological challenge but not working on the reports because those are just SQL queries with a nice format. The code is crappy because the development team had to stop in the middle of the warp core and mix it with some solar panels because somebody said solar power is the way to go, and then changed to a 2 cylinder engine to make it at least work.


The craziness I just described is day to day job for many people. This craziness creates the perfect alibi for everybody not committed to the project remain in the company, just doing the least they can like parasites. This craziness prevents the good people to be able to change things for better, because it takes them 4 times the effort of what it should be, lose hope and eventually leave. This also makes management not to trust employees, because the parasites are silent all the time without any idea, and the ones committed and with ideas have to work extra time to try to make them real, and sometimes it just turn impossible. A general sensation of failure is created making things harder to change.

Many companies would like to have a Ferrari at the price of a Méhari. Those do not like to pay the price of maintaining a Ferrari either. It's not the same insurance fee, not the same mechanics, and it's not the same oil consumption. Some other companies are rich, and can afford the price of a Ferrari, even when they spend 5 times the actual price of it.

So, what do you need to get the application you want?

  • Good people in your company trying to do the right thing. 
  • Commitment to higher quality. 
  • Good management pointing the right direction as a company with common goals for business and IT. 
  • Good communication between and within teams.
    If you lack any of them, you will never get the car you want, or the application you want. You will only get some pieces of it and most of the time a lot less than you expected. You will always get a Méhari.

    2 comments:

    1. I enjoy your post, great metaphor. I share your vision of many enterprise environments.

      ReplyDelete