The more I experiment with TDD the more I learn its values and what it does for me.
I am visiting our extended team in Shanghai and was tasked in cutting their release process by 50%. After some investigation it appeared a lot of time was spent ‘provisioning’ their builds to the dev/test/live environments. Our solution was to write a tool to automate the whole process. They where tied up with their market deliverables so this gave me one week (well 1/2 a week once the jetlag settled) to write the tool. Immediately I started thinking about enterprise solutions with ASP.NET front end for the whole extended team to use. Thankfully Craig our software architect rightly told me to focus on solving the problem first and extend it later.
So off I went and broke the problem down into smaller modules. Once I had a rough idea of what I wanted to do I jumped straight in and solo TDD’d my way through a component that takes our build output and shaves off all dead weight ready for provisioning. When I was done I was hugely satisfied.. this was a really quality piece of development. With my unit tests supporting this module I knew it was capable of the job.
However I had just spent over a day developing this component and I had another three or four of the these components to develop to be “done”. Does this mean I needed more time to do the job? I don’t think so, I think I just lost sight of the agile principles. Early delivery of working software that gets extended in iterations.
My learning’s from the whole experience:
- Don’t try to solve all the worlds problems on the first attempt. Pick a simple scenario that might not be suitable in the end but will help ‘build up’ the program. I know what your thinking… “d’uh”.
- Develop each component in parallel using the above principle so the whole system in developed in unison. That way if development is cut short at least the problem is partly solved.. and who knows that might be all that was required after all.
- Start with a prototype to prove the concepts before heading into the land of TDD. Good TDD takes time with great results, but there’s no point if the fundamental principle behind your program is flawed*.
What I cant understand is why I ended up making these mistakes. I’ve read the books and knew these things before I started, yet I still ran head first into them. I guess there is simply no substitute to making the mistakes personally and learning from them first hand.
* As is turned out my program wasn’t flawed but in retrospect there was a chance that 2 days worth of work nearly surmounted to nothing had I not been a little lucky.
