My thoughts on TDD after one small project

Mon, 23 Aug 2004 15:48:13 GMT

First, I must disclose that I really only did Test Driven Development in the beginning while coming up with the object model and basic methods. It worked out well for this. I found that it was much harder to drive the detailed design using TDD at later stages. Although, i'll give the approach the benefit of the doubt and say that it was my lack of experience using TDD that caused this.

The project that I worked on was a calculation engine that takes two objects, each with various numbers of subclasses(I won't bore you with the business details) and outputs numeric values. The computation is fairly simple but output is pretty detailed and isn't easy to see problems by simply eye balling the data. Unit tests worked out fantastic here. We have over 120 unit tests that exercise positive and negative paths. I can honestly say that if management came to us tomorrow and asked for another calculation scenario, we could introduce it and be confident that we didn't break anything else almost immediately. Pretty slick.

Although this was a very positive experience, there were some downfalls. When approaching a project with TDD in mind. I'm having a hard time determining how to estimate it. Since you are not doing BDUF (Big Design Up Front), the scope of change is quite unknown. If you haven't worked with a given project before(legacy or new), it would be very hard to estimate resources or timelines.

In my world at work, we are typically give a production date and then figure the timeline out backwards. This allows us to determine how many people it will take to meet the predetermined date. I realized, this approach is less than optimal, but I have to live with it. With this being the case, how can you not do BDUF?

Unruly Rambling - agile tag

My thoughts on TDD after one small project