Celebrating Liability

We may find ourselves celebrating liability.

Yes, I would

Is code a liability?

Yes. We own it after it's made.

Will programmers celebrate code?

Yes. We are easily impressed by cool software.

But would we celebrate liability?

Yes, but of course, stated this way, we know we shouldn't. To avoid this, we must be careful, intent on our real goals.

Know your tendencies

Some code is whiz bang awesome, easily admired and a good demo. We have to think about whether we really want that enough to pay for it. If we give in to our tendencies, the engineering team, will create a lot of really cool, overly-complicated puzzles of programs that scratch creative itches while solidifying our companies' long-term need for programmers. Rise above your tendencies.

Liabilities are harder to see when they come in shiney packages. Long term liabilities are harder to see when we get the sugar rush of a demo in the moment.

Create with care

How should we be careful when writing or evaluating code? We fully understand the problem to be solved. That problem is a higher priority, above and distinct from other problems. We only write software in response to that problem and only where we weigh the payoff as worth it. Remember, our judgement in weighing the payoff of designing, writing, delivering and running cool software, as a programmer, is impaired. Remember, all code is a liability, even the code that is a part of the solution to the priority problem. We don't want any more than that.

Minimizing liability means minimizing code. We don't have to codify every life or business practice. We do only where its existence is more helpful, less expensive, more reliable, more accessible, etc. to the program's users -- and, over the applicable time duration. Problems were and are solved without software.

Code is a liability because it makes demands. From the moment it is written, it can demand more of your time, vigilance, energy, creativity, money, understanding, trade-offs, observation, etc.

Celebrate!

What kind of code should we celebrate? The exact right amount of code, made and delivered in the simplest possible way, that solves the priority problem well for its intended users. That is a high bar indeed. When we make this code, we should celebrate!