Uncle Bobs posting The Start-Up Trap created quite a stir across the internet some weeks ago. This has also challenged me to think about what I feel about the disciplines (e.g. TDD) at a fundamental level.
I got swept by the testing wave early on, I felt it addressed a hole in the current practice. It also represented a standing of quality away from the current practices of that time. I was almost a fanatic TDD’er.
Uncle Bob spoke very clearly about TDD and the and other related disciplines and attitudes for software professionals to have. He made it clear as black and white and it is this “either or” (in an almost arrogant style) that provoked a lot of people the other day. He later followed up with the post The Pragmatics of TDD where he tries to explain to, those who not know his style all to well, that he isn’t being dogmatic.
For me – Discipline is the keyword in the discussion here. Uncle Bob writes about a start-up not allowing themselves to practice the disciplines because of “pressure”:
“Come back to that company in five years and (if they’ve managed to survive) they’ll still have the same attitude towards the rules that they had in the first phase..”
To my observation, this is often the case. People do not ever manage to break out of that style of working. Leading to software that we all have seen before – hard to change, buggy, time-consuming, person-dependent, etc
If the people in that company where highly disciplined, they would have broken out of the early “prototype-style” of working in the right time and morphed it gradually into something that can survive and be very agile and moldable for the lifetime of the business.
See Greg Young’s post with his own experience. Although I think he mixes over-design and the core disciplines a bit here. TDD and a “perfect system” is two quite different things. The difficult thing is to bring in just enough architecture and structure “just in time”.
Dan North has given this style of working a name – the “Spike and stabilize” pattern – where one prototypes and later brings it back to sustainable production quality. This is a style of working that requires immense discipline to use and is not for the common man. The mental and physical cost of stabilizing later on is very high.
A very, very few of the people I have encountered so far are truly disciplined (but they exist). And very few surroundings, i.e. businesses, allow people to exercise discipline “just in time” (but they also exists).
In theory we think that we can manage to exercise discipline when we need it, but there is a sad reality.
Therefore I would argue that the majority/average of us would in most cases be so much better off following the core disciplines as the default route.
As Jimmy Bogard argues, it always depends.
Off course need to learn inexperienced developers to think for themselves, but I would argue that in order to use a “It depends” and “not in this case” you should have proven that you can follow the disciplines. Think of the movie Karate Kid – you got to “paint the fence” and “wax the car” so much that it is becomes an integral part of you. If not, we will continue to see what we see a lot of today – developers not ever coming up to speed with the disciplines of our profession.
- It requires even more discipline to work outside the disciplines