RSS RSS feed | Atom Atom feed

My thoughts on TDD after one small project

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?



Re: My thoughts on TDD after one small project

Has this type of scheduling ever been effective or accurate in the past?

Re: My thoughts on TDD after one small project

Actually yes, somewhat. If you do BDUF, it's possible to come up with a path that will lead to an on time delivery. There is added risk with this approach since if any up front design needs to be changed, it will take a few all nighters to complete. That is, if it's possible at all.

Re: My thoughts on TDD after one small project

You can get pretty good at estimation after just a couple of iterations into a project. If resources, time and feature set are all fixed at the beginning of the project, that's how death marches (or their lesser cousins "all-nighters") happen. Though XP does not go for BDUF, it *does* go for putting together small enough story cards that your estimates won't be too far off the mark. When taken in isolation, you can usually estimate a given story card with reasonable accuracy, particularly after a couple of iterations on the project. The real key to successful, iterative project management is to give the customer everything they need to choose which set of features end up in the final release. Once they have that control and they start seeing regular process, they're a bit less likely to put the squeeze on the resources-time-features triangle. One last thing: on the project I'm working on right now, we wrote up a few "flesh-out" story cards. That was our way of dealing with stories that were too hard to quantify without more information. We spend a couple of hours with the customer and work through some of the details (producing more story cards) and end up with a much better idea of what needs to happen. With XP and TDD, you don't spend a lot of time up front designing the code. You do spend time making sure you know enough about what the final product needs to include.

Add a comment Send a TrackBack