Time to Restructure!

I love greenfield projects! They're a chance to start with a clean slate. A chance to do things right. After maintaining our existing apps for so long, we're keenly aware of everything that we'd do to fix them. A fresh start is a golden opportunity to take all those lessons we've learned and apply them in order to build a shiny, pristine code base that we can be proud of.

The New Project Rush

New projects are also usually a bit of a rush. The business team wants to make sure you can deliver by a certain date, so things move fast. And they often change a lot, too. At one point, the vision for the application was captured only by a set of written requirements, and maybe by some wireframes. And once you translate that vision into actual pixels that the business can touch, they might decide it wasn't quite as amazing of an idea as they had thought.

All of this leads to quick changes in code, and a lot of punting on the better solutions. "I'll come back and clean this up later," we tell ourselves.

The Breaking Point

After we do that long enough, we hit a breaking point. We start feeling the pain of our earlier decisions. It doesn't necessarily mean that the decisions were wrong, of course. If it got the product out on time and functioning right, then it probably paid your light bill and put food on your table. Good job!

Still, the code starts developing a complexity that you can feel. It starts weighing on you with every update you make. You know the feeling. We all do. It's the call to refactor, or even restructure, some major part of the application. It's a call to rework it into the design that, in hindsight, you now realize that you should have used to begin with. And when you hear that call, it's time to act.

Seize the Day

The problem is that there's a limited window during which you can reasonably act on it. The longer you wait, the more pieces of your code will depend on that complicated design you've got. And the more pieces depend on it, the more effort you'll have to put forth in order to correct the design flaw later.

Eventually it'll get to the point where the ROI simply isn't there. It'll take way more time to fix it than you can afford, because you've got new features you need to work on. So you let it go. You just do the minimal you have to in order to keep it working. At some point, you just try not to touch it. And when you find that inevitable bug lurking in it, you might even pawn it off on the new guy. Welcome to the team!

Heed the Call

Heed the call to restructure when you hear it, before that window of opportunity closes. I understand that it's not always possible, of course. You've got new features to build. The business team has its priorities, and rightly so. Sometimes that's just life. Just keep in mind that, generally, it will never be easier to restructure that design than it would be today.