I saw somebody else complaining about how rough iteration 1 is. Experience has taught me to be very, very pessimistic about how much recognizable business value gets created in Iteration #1, but I’m still surprised by how slow it’s going for me. It’s exhausting because everything you do you’re doing for the very first time. It’s like an iceberg. You’re setting up a lot of development ecosystem and infrastructure below the surface just to get that first dram of business functionality peeking out above water where the non-developers can see progress.
Progress is also slow in early iterations because the ratio of design time to code is much higher than any other time in the project. I think that if you were able to chart the productivity of a development team through the first couple iterations you’d see an S-curve. Productivity rises very slowly, then suddenly hits an inflection point and darts upwards before hitting a second inflection point and settling into a plateau. That first inflection point is what I think of as the “this is the way we do it” moment — that magical moment where the team understands how the pieces fit together and has the answers for the most common development tasks. At this point it’s a matter of how fast you can work. My goal as the team lead is to get to the “this is the way we do it” moment as quickly as possible.
Iteration 1 is critical because I think early momentum is so crucial to the success of a project. All of the best projects I’ve been on started very strongly out of the gates. The projects where things were muddled early on never completely recovered. I’ve always thought that one of the advantages of Agile processes is simply being able to feel momentum so much earlier instead of slogging through extended upfront analysis and design phases.
It’s important to work purposely, but I don’t want to cut corners on the development ecosystem because I think there’s so much efficiency to be gained from solid project automation. I don’t want the code to get too far ahead of the infrastructure because you never really stop to retrofit things later. To that end, just to do a couple story points worth of work, I’ve had to:
- Create a Subversion repository
- Set up a code tree, and downloaded or installed all the tools we’re going to use for now
- Create a build script (Rake)
- Install and configure CC.Net and CCTray
- Installed Mingle and entered the first batch of stories. I know there are some performance problems, but it’s been a joy to work with so far.
- Figuring out how I want to organize unit tests, and how to incorporate more BDD elements to write better tests — excuse me, specifications.
- Getting used to using an “AutoMocking Container” to make interaction tests a bit more readable
- Created a DataMother to put together object structures in unit tests
- Started creating a StoryTeller infrastructure this morning to express acceptance tests. I desperately want automated “executable requirements” from day one and unfortunately, I still think Fit style tests are the best answer in the .Net world. At least until IronRuby is ready enough to use RBehave on .Net code.
- Figured out how the StructureMap configuration would be bootstrapped in the application
- Figured out how I could run the app in “Stubbed” mode sans database and build the stubs. I’ve often found it useful to run the GUI without any backend to deal with UI coding.
- Build out an ApplicationShell, ApplicationController, IPresenter interface, and basic screen activation code. I’m trying to avoid BDUF, but it’s leaking in anyway.
- Get used to a different set of 3rd party controls. Collectively, the worst API’s ever created by man. Note that I’m not being specific about any particular control maker, because they’re all bad!
- I haven’t even touched NHibernate usage or configuration management and build processes for the database, but it’s coming soon
- Write a coding standard (TODO)
- Extend the build so that my tester and customer proxies can retrieve a numbered build at any time (TODO)
I might be bordering on a new development Antipattern, “Big Infrastructure Upfront.” But then, like a ray of light, I was suddenly able to just write code. With the Super Bowl coming up, there’s a football related analogy I like to make: “Broken Field Coding.” The ability to code without impediment because you’ve got what you need, the tooling is right we’re you need it, and the only thing you have to do is sprint for all your worth.
Anyway, here’s looking forward to the smoother iterations ahead. And ReSharper 4.0.