Architecture to take on design risk
Some of the most successful projects that I have worked on have started life as a “one day” radical hack. Normally with little more guidance than something along the lines,
- “I wonder why the boot sequence is so slow ..”,
- “wouldn’t it be good if …”
- “thats never going to work, why don’t we …”
If you look at TDD in isolation it smacks of upfront design cost, and I often feel that the investment in the test safety net itself leads to a practices that may put the programmers off of experimenting with radical and risky change.
I do write tests, and most often I write them before I write the code, but I have always had this nagging doubt that I am wasting my time, especially when working on a politically unstable project that may get canned or shelved.
It seems that Kent Beck also shares a similar love of just getting stuck in and seeing if a single days works is worth a go http://www.threeriversinstitute.org/JustShip.html
What tips and tricks are there for encouraging your programmers to efficantly think out of the box, and to take on a riskier change (in a controlled way)?
0COMMENTS