Thread by @PaulDJohnston

What? You mean... you mean... that software lives on beyond the deployment? Beyond the first few minutes/hours/days? Until you retire it? #sarcasm

I think we need a new phrase:

"Your code is for life, not just for deployment"

cf "A dog is for life, not just for Christmas"

https://twitter.com/mipsytipsy/status/1123809252034924546

I love @mipsytipsy talking truth. She's one of the few who simply nails it almost every time.

Too many devs fail to think about the effects of their code over any term other than the deployment and a bit after.

Maybe because their salary doesn't depend on quality over time?

If devs were paid a bonus based upon the amount of technical debt they created - the less they created, the better their bonus - would the world be a better place?

Because maybe that should be a thing we consider.

Too much time is given by devs/managers to "feature velocity" and not enough to "future technical debt mitigation". Not to say that "feature velocity" is a bad metric, but it's a metric that definitely misses the mark over the long term.

If you look at #Accelerate and the four key metrics that identify top performing organisations of lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage...

...ALL of these are IMPROVED by...

...working to avoid future technical debt.

Lead time - avoid future technical debt, and you minimise wasteful rework fixing technical debt problems that you could have avoided

Deployment frequency - automating your deployment is much easier when you're primarily focused on adding and updating features rather than fixing technical debt, which is often harder (downtime, data migrations etc)

Mean Time To Restore (MTTR) - if you have a solid automated deployment process, then it's much quicker to restore from a failure. Not only that but you have fewer technical debt issues to deal with because you've considered them more in advance than normally you would have

Change Fail Percentage - and if you do all of the above, then you'll clearly be failing less, because you're actually asking devs to consider the possibility of future long term issues ahead of time instead of not doing so.

So the whole mantra of:

"Your code is for life, not just for deployment"

makes a lot of sense to me.

And it's part of why a #serverless approach makes sense too:

medium.com/@PaulDJohnston…

Code is a liability. Today's code is tomorrow's technical debt.