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
Monday, August 30, 2010
Project description
"Mitt HP SM projekt är som en Rubiks kub med några extra dimensioner. Och med färger som inte riktigt passar ihop."
Eng: "My HP SM project is like a Rubik's cube with a few extra dimensions. And with colors that do not quite fit together"
Boy, I don't envy him ..
Eng: "My HP SM project is like a Rubik's cube with a few extra dimensions. And with colors that do not quite fit together"
Boy, I don't envy him ..
Thursday, August 19, 2010
KTM wishlist
I just tried the KTM 990 SMT, and as I am positively impressed, I am equally amazed how stupid KTMs can be designed and built.
The chassis is fantastic, it's quick, light steering, stable, powerful, and wheelie prone. Unfortunately there are some build and design issues:
The mirrors will probably fall off before your test drive is over. Why ? The mirrors on my Yamaha have never vibrated off. Are the Japanese smarter, or do they just give a shit?
The brake pedal is model 80's, like it's made in a shool workshop, kindof like it's bent from one piece of tin can, with a serrated edge. I know that KTM says they're about "Ready to Race" and such, but they should be equally about quality, since people are used to buying the Japanese passive quality, where everything stuck together stays that way, and engines never break down.
Another stupid thing is the instrument console, it's unreadable, and doesn't have a fuel meter. Why ? Why is that so hard ?
Until my here wishlist is complete, I'll stick to Yamahas:
- Fuel meter
- mirrors that don't vibrate off
- readable instruments
- better quality rearsets
- Better fuel economy
Peace!
Friday, August 06, 2010
Subscribe to:
Posts (Atom)