Time To Do It Over

When I was younger, I had a more senior person tell me many times: If you don't have time to do it right, when are you going to have TimeToDoItOver?

I would like to believe all this doing it over stuff, except I have only once ever been on a project where we got to do much over again. Most of the systems, hardware and software, we tried to get it right because we knew we weren't going to get to do it over - and we didn't. So I still try to take the time to get it right, because I am not likely to get to do it over. -- AlistairCockburn

We're not smart enough to do it right the first time, nor dumb enough to believe we'll get to do it over. So we refactor it as we go.

You aren't going to get TimeToDoItOver. Even you do convince them, chances are it will take longer and cost more than even you want. So what you have to do instead is to DoItOverAllTheTime. -- RonJeffries

Alistair, I just had a thought as I did my morning review of the rants. I think a difference between your excellent strategies and XP is that we do our cycles even more quickly than you recommend. With iterations only three weeks long, and the typical Engineering Task only a day, we get to revisit and refine our objects almost continuously. That makes what we do less like doing it over, but not at the cost of big investment when we're ignorant. Could it be? -- RonJeffries

You know I am a fan of XP and a defender if not proselytizer. It still represents an environment I have only been in once in 24 years. I made this page to see what can be said about the two environments. Can most be turned into one like you have? On the basis of this discussion, I am trying to shift our next project into one that can start small, deliver tiny, and evolve non-stop over time, as opposed to its current form as a 'project' which has a start, done and death. I also am trying to figure out how in the world I could have created a certain framework, which took me three weeks of thinking and experimenting and programming, in your fast-delivery life. So the open question here relates to the possible mapping of a design-once type of project to a design-many type. First guess says that it is connected with number of people on the project.

I keep rereading my own book to discover what I already am supposed to know that I keep forgetting to apply (funny how that happens when I get dropped into a different culture). I note here on p.84 it says "... people change their understanding of the problem on the scale of days and weeks. Iterative development by itself will not keep pace with these changes, as [it] operates on a time scale of weeks and months." Think I have to think some more. -- AlistairCockburn

I'd have never thought of portraying iteration as being an exclusively long-term phenomenon. At a fine-grained level, you can switch from growth to refactoring and consolidation at the speed of thought, as you spot opportunities to make things better. An individual object can get better on a fine grained time scale that is distinct from other elements of the current application, or framework as a whole. I'd wager this is what you do when you work on your framework. Iteration <Unfolds> (to borrow a Nature of Order notion) at different levels of scale in space and in time.

As a PastoralProgrammer, I got to carve out a niche where I convinced my employers that cultivating the system for the long haul was a good thing. So I got to do it for a good size chunk of the period of time Alistair didn't. It's not always easy, but I'd never go back to slash-and-burn coding.

-- BrianFoote

I'm not in Kansas any more, I guess. For the people I associate with here, these answers would make no sense, no slight intended. I find it intriguing and confusing to jump from a discussion with people like Brian who see iteration as a moment to moment thing, while refactoring designs over years, to a discussion where a change to an existing piece of software is considered a big deal, and you have to schedule iterations well in advance. Looking back at this paragraph, I realize I never was in Kansas and have no idea how the conversation would turn there (... or in which part of the city or state, for that matter...). I think CulturalRelativism? has finally overloaded my circuits and I ought to try ParochialAbsolutism for a while. :-) (I still don't know when I am going to get time to do it over.) -- AlistairCockburn

Moved from YouArentGonnaNeedIt

I had a more senior person tell me many times when I was younger, If you don't have time to do it right, when are you going to have TimeToDoItOver? I watch this discussion about XP having all this time to do things over, but I have only once ever been on such a project. Most of the systems, hardware and software, we tried to get it right because we knew we weren't going to get to do it over - and we didn't. -- AlistairCockburn

See my comment in TimeToDoItOver. We don't do it over. We DoTheSimplestThingThatCouldPossiblyWork. Then we revise, improve, refactor. The end result is we go faster because we don't add things we don't need, and when we add things we do need, we keep our nest clean. -- RonJeffries

Alistair, this sounds like fear talking. "We won't ever get to touch this again, so we will spend a bunch of extra time and add a bunch of risk right now, as much as we can make management stand, to try desperately for a better result we know we won't achieve, because we don't have the experience now that we would need to get that result." What if you chose to ignore your fear (and we all feel it) that you'll screw up? What if you just plunged in, confident that if you learn this time, you'll fix it before you go on, and that if you don't learn this time, you'll fix it next time you come across it, because you're sure to learn then? Might you gain enough productivity that you could spend 60% of your time "reworking" code and still smoke toe-in-the-water development teams? Might you have so much more fun not listening to your fears and erasing your naive sins that you would change careers rather than go back to your old habits? -- KentBeck