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
