Uncategorized

Slowing Down the Train

One of the hardest things to do when delivering software is slowing down. Deadlines are tight, and you only ever have time to write more code on top of the existing mess that is there. The train is running at full speed, but it’s not sustainable; not at this pace.

OK, so you’re responsible, and you queue cleanup tasks with each shortcut you take. Documenting technical debt is a great first step, but it’s nearly impossible to pay back with minimum payments only. Aside from the inevitable bankruptcy, there is another problem.

Design is emergent. Unless you’re brilliant or your requirements truly never changed since day one, you are going to make inadequate design decisions early on. It’s just a reality. By continuing to pile on cdoe onto a poor design, you are continuing to write legacy code. Things will never get better.

It’s not iterative development if you completely omit the refactor cycle in your loop. Eventually you’ll run out of track. The real question is: can the train be slowed down, or does it need to run its course?