Finally, A Sprint-Sprint!

I imagine SCRUM uses the term "sprint" for development iterations to emphasize the quickness of the cycles to deliver shippable functionality. As I've written about before, I'm implementing a one-man SCRUM development team. This last sprint began seven days ago and was complete last night.

That was, by far, my fastest development sprint since starting the project. I believe there were two main reasons why I was able to accelerate my development this time. 


First, I was leveraging the functionality I had already coded; i.e., code was re-used. This infrastructure was developed during the first several sprints. The app I am using is leveraging the Core Data framework so I spent several sprints wrapping my model objects with an appropriate API. Additionally I had decided to use custom graphics and a custom layout engine responsible for assigning frames for UIView subclasses. These two elements were heavily developed using TDD which motivated me to code the methods to test cases that were thought through beforehand, instead of coding to what I believed would be sufficient functionality.

So when the time came to add features, I just had to make calls to existing methods to get it done. 

Secondly, this was the first sprint when I had to make the conscious decision to abandon an algorithm design targeted for the general case when I could get away with a design that would fulfill the use case of my app. Yes, it was a design driven by assumption, but here those assumptions posed negligible risk. 

(Were I designing a public API, however, that kind of strategy wouldn't fly.)

This further emphasizes the idea that TDD requires much initial overhead, but pays off handsomely over time.