When Not To Iterate

0 comments suggest edit

As a kid, one of my favorite tools I had was a shiny red cased Victorinox swiss army knife. I’d carry that sucker around with me everywhere, using the main blade to tackle nearly every problem like a caveman with a stick. Until one day I sliced my finger trying to stick a paper cup to a tree so we could throw ninja stars at it, but that’s a story for another time.

As software developers, we have a swiss army knife of approaches to tackling any given problem. And often, we like to pull out the same blade over and over again. For example, one tool that we pull out nearly all the time is the tool of “iterative” development.

As Atwood said in the comments to Micah’s post on harmful requirements, you gotta go “iterative”.

However, sometimes you really do need to pull out a different tool in your swiss army knife. For large projects, breaking it up into phases and iterations makes sense most of the time, but there are times where an iteration itself may be longer than other iterations. Sometimes such an iteration itself becomes a mini project that requires BDUF.

Here’s a scenario to chew on. Suppose an iteration of the project is to produce a report based on data imported from a couple external sources. The report only has to produce a single number based on a calculation applied to the data. This is the type of problem that may not lend itself well to iteration. The client is interested in the final number, not any number in between.

Sure you can have an iteration in which you mock up the report to show the client to get something in front of them, but even this can be dangerous because you’ve set the expectation that you can deliver the report. But do you know that until you’ve analyzed the data?

This is a situation we found ourselves in. The requirements appeared to be describing a specific calculation we needed to produce. But after a careful look at all the fields we were getting in, the data required to produce that report just isn’t there. And we won’t be getting that data. Yet we have to produce this report by Monday. It seems we’ve walked to the blackboard to solve a series of two equations, but each equation has three variables. “Does Not Compute”

It seems to me that this is a classic situation where some up front analysis would have saved our butt and set expectations properly. Unfortunately, we weren’t brought in to this project till later and had to take it on faith that the analysis had occurred, but it was lacking. Someone, anyone, should have looked at the columns of data we would be receiving, and reconciled the data with the calculation we would be producing. I’m not sure how we can iterate ourselves out of that problem.

In our situation, it may well be that the real calculation we need to produce is much simpler and less useful than the one we thought we were going to produce. So we may be out of the fire on this one. But should the stakeholder disagree, we’ve got issues.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

3 responses

  1. Avatar for Jeff Atwood
    Jeff Atwood February 1st, 2006

    > But after a careful look at all the fields we were getting in, the data required to produce that report just isn’t there. And we won’t be getting that data. Yet we have to produce this report by Monday



    And without an interation (eg, hey, let's try implementing a skeleton version of this report), how would you have known this?



    Maybe you guys are smarter than I am, but my poor brain just can't anticipate all the problems I'm going to run into without actually starting some of the work.



    p.s. why is your blog so slow to load? Is it the hosting??

  2. Avatar for Haacked
    Haacked February 1st, 2006

    What do you mean by skeleton report? A mockup that shows what we're going to calculate? That wouldn't have helped in this situation. We can build a mockup that shows a nice number, but may not be based in reality.



    We'd would need to have built a report that actually used real data (or sample data as close to real as possible). That could be a skeleton report (no formatting) for sure.



    But to build that skeleton report, we need to look at all the data and figure out how to do the calculation. That's up front analysis.



    Instead, we went along building all sorts of things, saving this report iteration for last. Figuring that we'd have all the data in the system and be able to create the report. We were wrong.

  3. Avatar for Jeremy Brayton
    Jeremy Brayton February 3rd, 2006

    Reports are almost always an after-thought in any software. You simply cannot iterate this kind of stuff with skeleton reports or mock ups because they'll just be words on a page with very little tie-in to the actual product. They do however closely tie in with data collection (as in this case the report was your dataset).



    This means that in most instances there will be BDUF at least for the data side, which isn't a stretch. Keep putting report mock-ups using real data in front of their face until the client signs off on it. Then you can build a UI and framework around the data you're trying to capture in iterations. You have the end result: the report. You just now need to work backwards giving the customer a scheme they can actually use to put this data in. It's like solving a maze by starting from the end. Starting from the end has fewer paths of failure which strangely correlates to most development as well.