A Catch-22 for Software Projects

| Comments

I’m sure many people have hit upon this realization before I, but bear with me, I’m slow.

These two statements are completely incompatible:

  1. The end of the project the WORST time to change the design or refactor code.
  2. The end of a project is when you BEST understand the problem, and can produce the optimal solution.
As your project reaches the endgame, you want to be putting on the final touches. Fix bugs, performance test, get your deployment ready. Changing things, even slightly, can introduce wobbles and instability. The last thing you want is for things to be “good”, then do some refactoring that breaks features that have been built and tested.

Sadly, by the end of the project you’ve also become an expert in the space of the particular problem you’re solving. You can see flaws with the initial design, and ways to make the code more maintainable. If you had these piercing insights near the start of the project, it would be great; you could go refactoring everything without pissing anyone off. But at the end, things are delicate, and all you end up doing is saying things like “Ooooh, we TOTALLY should have done that part like THIS”.

I suppose this is an argument of scrum-style iterations, where there’s almost always a Next Time, and it begins with refactoring the existing solution.

The alternative is to never go back, and in doing so condemn all future peeps to maintenance hell.

blog comments powered by Disqus