Only Software matters

Experiences in software development

Do you want a car with wheels, brake or throttle? The Software development paradox!

Posted by Patroklos Papapetrou on May 30, 2014


Imagine that you want to buy a new car because the old-one is … really old, you got sick of it and you need a change. You go to a car dealer, you see a couple of models that you like and you ask them for some details, pricing etc. The salesman full of smile replies to you with the following question:”Do you want a car with wheels, brake or throttle?”. Note that these are XORs, You can have only one of them. How would you react? Don’t answer … it’s a rhetorical question!

Imagine now that you work for a software development company and a customer wants you to build a system for an online ticketing platform. Would you (or your sales department) ever ask him to choose one of the following : “Reliability, performance, code quality, alignment with business requirements”? Of course not! So why do we make such choices during the development life-cycle? Why do we sacrifice so many and obvious things when we write software? And please don’t tell me that we don’t have enough time or enough budget. We do have time and budget to fix all these bugs that we created because we have made such ugly choices, right?   

I don’t understand why I have to choose between doing the right things, over doing the things right. I don’t understand why I have to write performance-friendly code no matter how difficult is to understand it. I don’t understand why I have to make choices. Would you ever buy a car if you knew that there are no security tests before the car gets into production? Would you ever buy a car if you new that the interior is from such (poor-quality) materials that they’re going to break after one month or melt during a warm day?  So why do you build systems like this? Why do you allow yourself be a part of that? 

Unfortunately, everyday we make such choices or we are forced to, by these creatures called managers and It’s really disappointing that we don’t learn from our mistakes. So wake up!

Managers : Listen to your senior and experienced developers. Even prime-ministers have ministers and kings have consultants! (nobody is perfect)
Developers : Fight for your right to achieve perfection. Fight for your right to write code you’re proud of and creates less bugs (nobody is perfect)
Customers : Fight for your right to get high-quality software that meets your business requirements. It’s your money after all!

 

6 Responses to “Do you want a car with wheels, brake or throttle? The Software development paradox!”

  1. Alex said

    There is a cap theorem. The perfect software by all criterias will cost a lot. Have you seen crossover that can be used as racing car? Different type of cars have different pros. and cons within different quality criteria. And it is our reality.

    • That’s true! As a matter of fact I mentioned twice in my blog that nobody is perfect 🙂
      But at least all cars have the same level of features or the same level of security,quality etc. right? My point is that in many software projects we don’t care about quality or we don’t give a shit about performance… which is not the case with cars

      • cblinchris said

        You are comparing “on the shelf” products (cars) with “built” products (software).

        If you compare “on the shelf” cars and “on the shelf” softwares, this is the same : this one has better quality but cost twice more so I will take the low cost version.

        Now, back to built product.
        If you build a house, some entrepreneur do not care about quality or energetic performance but cost less.
        So this is really like building a software

        So I agree that our industry needs developper who fight to achieve perfection, but I also know that our reality is customer wanting a porsche for the price of a xxx

      • No, not all cars have the same level of security, quality or features. Yes, they all have some basic features, just like all web app can be used within a browser, but there are a lot of things that are not standard issue. Should I remind you that there used to be a time where air bags only used to be in $ 100k+ cars? Even today, there are some active security features that are only present in $80k+ cars.

        Today, we are also redefining what a car is. Look at the Tesla Model-S for instance. That’s more like a spaceship than a car, yet in a few years, we’ll consider it standard issue. The big difference is paying 10k for a car will get you some wheels and hopefully no fatal accident. Paying 80k for a car will get you a car so secure that it breaks the test machine.

        To bring this back to your argument. No, we don’t have the time or money to develop proper software because people are just not willing to pay for it. Yes, they might decide to fix the bugs later on, but don’t forget that a hole in a bottle is not a problem until the water gets high enough to reach.

        We keep on trying to find new ways to write software. Scrum, Kanban, CI, gated-checkins, unit tests, meta-programming, object oriented programming… All of these things brings nothing to your client. They are not features, yet we push so hard to use them and invest time and money in them. Why? Because they make us more efficient so that our client can actually afford to pay for our time.

        This is the whole idea behind being agile. Small, incremental steps. This is why the car you bought today has more features than the one you got 10 years ago. This is also why it is a lot cheaper than a high class BMW or Mercedes.

      • Thanks a lot for your feedback guys and your point of view with which I agree. It’s very correct.
        To be honest, my thoughts when writing this article was mostly on some internal parts of the software (call me Source code) rather than features or functional requirements. I was thinking about the way we build software… and not the features we decide to implement or not.

        In my mind a wheel is like Unit testing in software development, a brake is like code quality standards etc.

        So maybe it wasn’t the best parallelism to make with the car but I wanted to point out that some things (throttle, wheel) are so obvious that it’s out of the question to do them or not. And the same idea applies to software development as well.

  2. John said

    I believe the problem is the dynamic nature of code quality. High quality means to some, that future changes are easy to implement because of a smart architecture. Unfortunately this will result in a lot more work and cost than neccessary for the present features. Thus what I strive for, is 1. acceptable code quality with great readability on experimental/basic features, that may or may not be changed in futures, but 2. extensive refactoring on anything that gets changed in future, to allow for those changes to be not worked-around somehow, but integrated properly. The crucial aspect here is the great readability, because you will probably have forgotten your work by the time the change is required, and refactoring unreadable code with all its connascences is no fun!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: