Cost Of Time

“I have only made this code more complex because I have not had the time to make it simpler.”

   -- Grady Booch

Getting things right takes time. Making things simple takes more time. The question is, how much time do you have, and when do you have it? Expediency says make it work and move on. But that leaves you with the complexity. And complexity leads to drag.

The question is, how do you deal with the drag? That’s easy. You put in the time to make it simpler, less complex, easier to work with. But when? When you need it, of course.

The trick is figuring out when you need it. You don’t need it right after you implement and release it. It’s working, so doing extra work is taking away from adding more customer value. It’s probably not when you need to make the first change. Chances are the change is small and specific. You haven’t lived with the system that long so you still don’t have a good understanding of system interactions yet. So you make the simple change. You go through that cycle a couple of times and notice that it’s getting harder to make the simple changes.

That’s when it’s time to put the effort in to make things simpler. At some point the drag of the system means the amortized cost of making the system simpler and cleaner, over the next N changes, is lower than just making the changes as they are needed. Once you make things simpler everything is faster.

And that’s how you maintain velocity. Not by adding people to a team. That just increases the number of connections and slows things down. It’s not by doing more BDUF. You don’t know what you don’t know, and that just causes more rework. And it’s certainly not by taking on more tech debt. Over the long run the interest on the debt will make it so hard to get things done that nothing happens.

So don’t let perfect be the enemy of the good. Make it work, however complex it needs to be to work. But when the time is right, go back and make it simpler.