Monday, August 30, 2010

Good quality code vs value for customer

In our programmers discussion forum, the following discussion emerged: one party argues that value for customer really means "quick and dirty" solutions. Code that works, and is fast to write. The customer never knows the difference, and is happy that the job was done fast. The other party argues that so called "good quality code" written "by the book", following good design principles, such as using interfaces, patterns, well written comments, and naming standards, might not take much longer to implement, but will be cheaper to maintain, and be of better use to the customer.

Proffessionally, I've seen a couple of combinations:
* Uninterested customer & technical leadership, some interested developers. This implicitly means quick and dirty
* Uniterested developers. This means that everything will be barely usable, regardless of interest from customer, or technical leadership.
* Technical leadership that is into name dropping, or buzzword bingo. Here, if you (the developer) are interested, you could actually do some good. You can write good quality code, because the technical leader doesn't understand what you're doing, and when you're done, you explain nicely in a short email how well the code is written, which principles you have used, and your technical leader will be happy to use that in his report to the customer. Job well done, everyone is happy.
* Interested customer, less interested technical leadership, or lack of development skill. This usually ends bad.

The analogy with good quality code vs bad quality code: it's like good or bad engineering in cars. First, when the car is new and shiny, a Renault Clio is very nice. Smells new, spins like a cat, and life is good. After a couple of months, things start to happen. A rubber sealing falls off. A plastic knob cracks. "It was cheap, I can live with that" , you say. Then, the headlight goes out. No worries, I'll stop by the gas station, and buy a lamp. You buy the lamp, and start fiddling, but you can't really reach inside to pull out the bulb, because there's no clearance between the battery and the headlight. So you have to take it to the mechanic, who will HAVE TO lift it up, UNSCREW THE WHOLE WHEEL ARCH PANEL (!!! this is actually true) in order to get to the headlight. This will cost you an hour, and probably around 150€ or so. And this every time a headlight goes out, so to be on the safe side, you have to replace all three lamps at the same time.
Combine this with some notoriously bad french car electronics, and you have lamps going off pretty often.

Now compare this with a slightly more expensive Volkswagen. On the VW, you could change the bulb in about 5 minutes. Yes, you've payed 3-4.000€ more. Will that money be a waste? How many times can you change bulbs on a Clio for 3000€ ? Say 300€ a year, because the bulbs could burn out on both sides in one year, as on my old Mitsubishi Galant. So 300€ a year, times 10 years. In ten years, you've saved 3000€ on bulb changes only. What about the other bits and pieces that work right now, but on a 10 year old Renault, they need to be changed? What about the rust on 10 year old french tin can ?

How much does that 3-4.000€ extra mean when you start thinking like that ?
Why do people understand the logic when it comes to their own car, but not software ?

I've yet to see interest in good quality code from all parties. It must be as in all other businesses, most of the people are mediocre, and just want to go to work, worry as little as possible, make sure they don't have to answer any difficult questions so noone notices how stupid they really are, and hurry home to collect their paycheck.

Please take your time and comment on the above

3 comments:

Adrian said...

A colleague writes: "I have met much resistance every time I have tried to introduce test-driven development or extensive use of refactoring in development projects, also from other developers and technical project managers that should be familiar with it. I still hardly understand why that practices that have been so honoured of experienced developers, gurus, for so long time is so hard to introduce. For test-driven development have I a theory that the development would consume a bit more time compared to development without use of automated tests but that the test-driven development will be fastest if the comparison includes the time for the formal tests performed of a dedicated test resource. When a lot of mistakes already have been caught of automated tests will the formal test consume less time than otherwise."

KC said...

Interesting post. I generally agree. It's a well established fact (taught at universities) that 70-80% of a system's total cost of ownership lies in the maintenance, further development and phase out stages, so the customer is really only seeing about 20% of the total price of the system being developed in the first versions. And that means if you do take too many shortcuts in the first stages (bad design, quick and dirty spaghetti code) the cost of maintaining the system will be much bigger than they would be if the system was properly designed and written.

But there is a valid point in the customer's view about keeping it simple, because too much use of advanced design patterns, and heavy cumbersome methodology (RUP etc) gives too little customer value to be motivated. That's why agile paradigms are winning these days, they're a reaction of the over-designed "beautiful" advanced design that took forever to implement, barely worked in real life and suffered from bad performance after going in production.

So a balance in between these is what I personally prefer: Good design, but don't overdo it. Think scalability, don't hard-code stuff like a newbie but stay lean and agile and adapt. Early wins, release a quick prototype, collect feedback and improve continuously.

But what has poor Renault done to you to deserve the bashing ;)

Adrian said...

KC: I fully agree. Don't overdo the design, don't "overagilize" either.
And definately do it right from the beginning.