I’ve got the Iteration #1 Blues

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:

  1. Create a Subversion repository
  2. Set up a code tree, and downloaded or installed all the tools we’re going to use for now
  3. Create a build script (Rake)
  4. Install and configure CC.Net and CCTray
  5. 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.
  6. Figuring out how I want to organize unit tests, and how to incorporate more BDD elements to write better tests — excuse me, specifications. 
  7. Getting used to using an “AutoMocking Container” to make interaction tests a bit more readable
  8. Created a DataMother to put together object structures in unit tests
  9. 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.
  10. Figured out how the StructureMap configuration would be bootstrapped in the application
  11. 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.
  12. Build out an ApplicationShell, ApplicationController, IPresenter interface, and basic screen activation code.  I’m trying to avoid BDUF, but it’s leaking in anyway.
  13. 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!
  14. I haven’t even touched NHibernate usage or configuration management and build processes for the database, but it’s coming soon
  15. Write a coding standard (TODO)
  16. 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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Jeff,

    Sounds like you’ve got something to say.

  • http://agilology.blogspot.com/ Jeff Tucker

    @Jeremy
    Ok, you win, you’ve finally inspired me to start my own blog. I guess I’ll have to stop posting blogs in the comments of other people’s blogs now

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Spatz,

    It’s the style of development I want to do. I want, and the app certainly justifies, to work with a domain model approach first, and deal with the database second. NHibernate lets me focus on my Domain Model without having to contend with the database quite so much while I’m writing business logic.

    As to having VS2008, I’m assuming you’re referring to the two new ORM’s in the CLR. Linq to SQL is very oriented towards data-centric development like reporting and CRUD apps and isn’t what we need. I’m not touching Linq to Entities until they get the Persistence Ignorance story in place and do something to simplify the configuration. For that matter, Linq to Entities is very data centric as well.

  • Spatz

    Why do you need NHibernate if you’re using VS2008?

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Jeff,

    Go post this on your own blog instead of hiding it here in the comments!

    “I use Teamcity instead of cruisecontrol because it totally owns cruisecontrol in that it’s easier to set up projects in it.”

    I wanted to like TeamCity, but I can set up CC.Net in about 15 minutes now. I didn’t like the wizards when I was playing with TeamCity.

  • Jeff Tucker

    I like to run a pattern that I refer to as “no-huddle offense” (to use another football analogy).

    What this means is that you treat the act of creating a project as a project in itself. I have scripts and stuff that create project structure, I have a template for a build script (and I’m working on automating the build script creation too). I have a template database install script. I have a template for local settings (and yes, I flagrantly stole that idea from JP). I use Teamcity instead of cruisecontrol because it totally owns cruisecontrol in that it’s easier to set up projects in it. DRY, remember? This applies to your project infrastructure also.

    It also means that you update your “project” project every time you change something that’s a part of your development project. If a new version mbunit comes out, you update your master externals folder at the same time as the externals for your project. If I need to change the way my local config template works (like supporting Oracle connections), I change the master template in the same way. If I start using a new tool that needs build automation, then the ${references.external.standard} fileset in my master build template gets updated to include that dll.

    The final thing it means is that you do not add any new tools into your project (even if they’re in externals) until you actually need them. Even if you know that you’re going to use them in the future, don’t bring in infrastructure support for them until you actually use them. This sounds counter to what I just said, but the previous paragraph just means that I have tools ready to use in a standardized format. Just because I have Spring in my externals directory doesn’t mean that I start referencing it and create an empty configuration file for it on day one. I create that when I actually start using it.

    The last thing to remember is that when you’re developing code, accoding to the Agile manifesto, working code is the best metric for measuring progress. Pick a story, and write the code for it. Hard code your factory implementations if you don’t bring in Nhibernate just yet (particularly if you only have one factory). Want to use generics for your factories? Great idea, but a generic factory for a single entity is completely useless. Just write the code and refactor it when you have more than one entity. Hard code the implementation of your factory interface at first.

    Want to start working on the UI? Create your presenter by asking the question “As a presenter, what do I need in order to live?” and the write an interface for that service and then hard code the implementation. Don’t plan. Don’t think. Don’t try. Just write the code and refactor it as you need to (YAGNI4LIFE). Remember, the benefit of being agile is so that you can get rapid feedback on working software. That’s why you release in cycles, that’s why you unit test, that’s why you use continuous integration. The faster you can get code out there that works, ANY code, the more likely you are to be able to get that feedback and spot problems. Setting up your project infrastructure does not create working code, so minimize this task by following the principles of good design and only ever doing what’s necessary to the project at the time.

    Hell, I think I need to just go ahead and create my own blog already so I can go into this in more detail. It’s almost impossible to really defend my points in a blog comment and I sense a great disturbance in the force, like hundreds of readers suddenly cried out and then lit their flamethrowers. . .

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @DaRage,

    You might be right, and that’s part of the reason I wrote this post. On the other hand, everything I’m doing is being done for the sake of going faster. CI, build automation, database scripting automation, test automation are all things that’ll make you go faster, and retrofitting the tests at least is a bitch.

  • http://www.bluespire.com/blogs Christopher Bennage

    It seems to me that a lot of the work is due to the “youthfulness” of our tools (I deliberately avoided the word “immaturity”). As such, I’m looking forward to the day when all of these project infrastructure tasks will take less time and energy.

  • DaRage

    That what happens when you focus on technology and not on solving the problem at hand. But what can you do, geeks like playing with technology and software is written by geeks. I prefer starting with with a minimal infrastracture and building it as the project evolve.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Scott,

    Bad wording on my part. I’m talking about this: http://nat.truemesh.com/archives/000714.html

    I think of them as “DataMother” as opposed to a more static ObjectMother

  • http://www.sleepoverrated.com Scott Cowan

    Hey Jeremy,

    what do you mean by DataMother?

  • http://kentb.blogspot.com Kent Boogaart

    > Note that I’m not being specific about any particular control maker, because they’re all bad!

    I think I know who you’re talking about . . . might see you on their support forums! :)

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @All,

    Part of this was from “Iteration 0″ not being productive enough. Iteration 0 was spent on the story backlog which was great, but I didn’t have the build server available, so no CI setup.

    @Ayende,

    I believe that I can produce a far more readable test vocabulary with Fit testing than I could with Spector or NBehave. RSpec is tempting because of the plain text capability. Jimmy, Joe, and the gang may get that into NBehave, and that would change the equation. Except that I’m going to put it into Fit as well.

  • http://chadthedeveloper.blogspot.com/ Chad Sturtz

    We always go through a Sprint 0 to kick off a project and try to keep it to 2 weeks if possible. During this sprint we set up our CI environment and source code repository. Also, this is the point we try and decide what technologies or open source packages we’re going to use. There are more items I can list here, but I’m sure you get the picture.

    When it comes to design and development, there usually isn’t any during sprint 0. That’s not to say that if the team felt there was additional bandwidth available during the sprint they can’t take on any user stories. However, the point is, Sprint 0 is meant to enable the team to hit the ground running Sprint 1. That’s it. I don’t think there’s any anti-pattern there.

  • http://www.ayende.com/Blog/ Ayende Rahien

    Jeremy,
    Please check out Specter.
    It has a lovely syntax, and it just came out with a new release.

  • http://www.geekswithblogs.net/robz Robz

    Assuming this is what we call Iteration 0, this is where we bounce the big ideas off of each other and talk pseudo code quite a bit. We set up our infrastructure here as well. A lot of exploratory items happen here and we research some of our possible paths. I agree with what you said where you are waiting for productivity to go up following the first iteration. That always kind of sucks, but you get past it eventually. :D

  • http://jimmybogard.lostechies.com Jimmy Bogard

    Splitting hairs but:

    RBehave => RSpec’s Story Runner

    RSpec swallowed RBehave, but NBehave swallowed NSpec. Go figure.

    Scott has some interesting ideas on organizing specs around concerns, which may or may not be classes.

    We always called this first iteration “Iteration 0″ just so there wasn’t much expectation on delivering too many features.

  • http://weblogs.asp.net/bsimser Bil Simser

    It happens all the time. I’m just spinning off a project that I had to do solo (sort of and trust me, without a story wall I was screaming every day of the last 3 weeks) and now have to start up 2 new ones. The advantage I have is that I hover on projects, kickstarting them, getting the architecture baselined and starting the developers down the happy-happy-joy-joy path. I think all projects need this bootstrap and it starts with one person. Too many cooks spoil the pot as you have guys stepping on each others toes. Frankly I just hole myself up for a few days, spit out the source tree and a few integration tests and get the team running on the first iteration. I float in the background for a few iterations, jumping in to either mentor guys or pick up small infrastructure-like tasks (like fetching names from AD or something silly) and let the guys do the good stuff. Having more than one person do this is an exercise in futility as you’re moving things around and trying out new ideas to refine your reference line. I usually don’t even check the code in until the 2nd or 3rd day, and usually real concrete classes don’t manifest themselves until the team is onboard or theres some real requirements being delivered. Cheer up, iteration 2 is just a few weeks away!

  • http://jayflowers.com Jay Flowers

    I love:
    I don’t want the code to get too far ahead of the infrastructure because you never really stop to retrofit things later.

    That is so true.