I’ve been a TDD zealot for the last 7-8 years. I take pride in my code being well tested, my solutions being user friendly and my design being test driven.
When I test I know my system works. I sleep like a baby. I have a balls of brass. I can embrace change and laugh at how easy it is to add new requirements.
The thing is, in my life I’ve seen a fair amount of big systems that are terrible. They all have one thing in common. Everybody hates them. Programmers, users… but they do work, sort of. They are slow and buggy but nevertheless they deliver some value to the users.
Enterprise is euphemism for lame systems that barely work for 300 users?
Oddly, in many of those terrible systems funny thing happened. After a while guess what? People involved (users and programmers) made those terrible systems work (just enough) and all of a sudden you have a winner. Bigger the system, bigger the win. Bigger the mess, bigger the ecosystem of additional companies making it all work.
Think Windows & antivirus for example.
I wonder how smug IBM felt when developing OS/2 with all the cool stuff…and than a big nothing happened. Right now you might be thinking that I’ve lost it. You are ready to click away… but let see some examples:
World War II Tiger vs. T-34
One of the most advanced features of the Tiger was its assembly process. Flat section armour plate was used throughout the assembly process, which allowed the use of heavy armour. Various parts were made as one complete unit complete with interlocking joints that made assembly a quick process. Rings a bell? They where too heavy for most bridges, but it was not problem since they’ve added snorkel?! (later abandoned). However it costed staggering 250,000 marks. Meanwhile Russians had a pile of crap. One Tiger could easily destroy multiple Russians cans. There is one minor detail; at the end of the war Russians manufactured 1.300 T-34 monthly and Germans managed to produce 1.500 Tigers all together. It was not a coincidence it was a trade off. Did quality matter? It did, but not all that much for the bottom line.
Some other factors were more important than mere quality.
They were able to match Tiger quality later on while winning the whole time. By the end of the war, other tanks had been developed that outclassed the Tiger based on the lessons learnt on low quality mass production which also secured the front.
Bradley Fighting Vehicle
Development started at 1964 and since then project requirements changed a couple of times (big changes)… I don’t know if “Pentagon Wars” have any truth in it, but it does look a lot like a massive project gone awry. They’ve pulled it of just on muscle power and hard-as-opposite-to-smart work. The only guy that insisted on quality was force-retired (Coloner Burton). Eventually 17 years and 40 billion dollars later they’ve managed to slap together product that is in use even today. After a few additional iterations based on combat experience it even became good enough. Prototype that will replace Bradley is planned for 2015. In software project terms this is considered a success. Did it matter that quality suffered most of the time? No, not really.
Elevator
I sometimes ride a buggy elevator near where I live. You need to press “floor 3” the display shows “floor 2” and you actually go to “floor 1”. Am I unhappy? Am I not using it? The thing is I don’t care and it doesn’t stop me from riding it. When someone new is with me I even get to crack jokes about it. All in all it is a complete win despite obvious flaws.
Conclusion
I will not stop test driving my code. I like the immediate feedback and the power I get from knowing that system is working. I like evolving the code in an organic manner. I like to garden and polish code. This post is acknowledgment that the other side has it’s strong points. It is not luck that they also make their way work. You can balance your trade-offs in a different constellation and if you are smart enough you may be in equal or even better position. It is not quality that matters, but being a champion.
Champions are underrated because of industry obsession with silver bullets. Throw any technology at champions and give them a goal. Being a champion is much more important than anything else. It is a known fact that OOP projects had much better success rate than procedural paradigm at the beginning of OOP wave. Reason was that you had all the champions trying out this new cool stuff. After a while the numbers evened up back to the average.
It just happens that today rage is all about Ruby, Clojure and what not. That means that you have a bunch of champions piled up. I bet all of those guys would pull it off in any technology and with any development technique.