Technical Debt - II

Before I jump to solutions, I’d like to take a moment and talk about entropy.

(From the site "If you assert that nature tends to take things from order to disorder and give an example or two, then you will get almost universal recognition and assent. It is a part of our common experience. Spend hours cleaning your desk, your basement, your attic, and it seems to spontaneously revert back to disorder and chaos before your eyes. So if you say that entropy is a measure of disorder, and that nature tends toward maximum entropy for any isolated system, then you do have some insight into the ideas of the second law of thermodynamics." -> It's a good read.)

If you think about it, every human accomplishment is a temporary battle against entropy.

Great Buildings are built, last hundreds of years ... and fall.

Cities become kingdoms that become empires, reign thousands of years ... and fall.

Even the great sphinx of Egypt, built in a warm, dry climate with little weather, is feeling the effects of age.

So it is with software. The typical software system might last ten years, fifteen if it is wonderful, but, eventually, the center will not hold. The code will not work on the new operating system, the company will fold, or the company will merge and turn off the legacy system in favor of the new.

In some ways, developing software is a battle against entropy. In some cases, just getting the code into production is a losing battle.

Once the code is in production, the battle starts all over again. Each maintenance change is the opportunity to write a clever hack or make an improvement. In each case, we can trade a little time now for a system that is slightly worse. With each change, the overall impact is un-noticable – but add them up, and we’ve got a mess.

At the same time, no one wants to develop the perfect, new new thing, with beautiful code and perfect documentation – only to be six months late, miss a market window, and have the company go out of business.

The question isn't "to accumulate technical debt, yes or no?", but instead "Just how great can we make this system given our constraints?" (Little things like time and money), "How can we trade off or ignore those constraints in order to have less debt?"

In other words "How much can we invest in this system to save time and money later?"

That is a hard question. I assert that is must be asked and decided consciously. Socrates said the unexamined life is not worth living, and I would add that the unexamined process results in ... crappy products.

We all know the "right thing to do." It's just hard to do it.

So I would like to propose three ways to lead conversations towards less technical debt, focused on –

A) What *you* can do as a technical contributor
B) What you can do as a technical contributor to influence other members of the team
C) Options for management

See you next time ...