How to Leverage Technical Debt

This is a great way of putting it! It's true that many middle managers and business/sales people do not respect this line of reasoning, but that is their mistake rather than a genuine or well thought out business decision -- which is why it bites them in the end. I would take this further and say that it's often a matter of professional disrespect to pay the architect's skepticism such little heed as to override the architect's vote to constrain feature creep. Self-discipline is hard!

One of the most challenging aspects of this in real development jobs is that shrewd managers and/or business and sales workers are very good at deflecting blame and creating political situations in which they are able to pretend to have supported the "right" choice no matter what the outcome.

So, very often, when features get hacked into the system against the architect's advice and it predictably causes untenable debt growth and parts of the system fall over, what is the first thing you hear? That it is the engineers' fault for not building the system correctly.

It's very rare that an architect can successfully communicate the problem of excessive feature growth and convey after a system failure that it was not really the engineers' fault, rather the fault of everyone forcing their poorly conceived features to take priority.

In a healthy development environment, everyone should be hearing "no" very, very often when asking to add features, especially when they come to you as if it is a big emergency that some market phenomenon mandates that the feature must be added right now.

If you find yourself in an environment where your employer does not empower you, as a developer, to say "no" in that situation definitively, then rather than trying to fight any blame wars about whose fault a system failure was, just get your resume ready and leave. There's no need to put up with that sort of poor engineering culture, and plus, wouldn't you rather put your name on something of quality instead?

I enjoyed the article, although I disagreed on some minor points, some of the broad strokes seem solid to me. Very thought provoking.

I think it's interesting to contrast the thrust of the article with Ward Cunningham's original definition of technical debt: https://www.youtube.com/watch?v=pqeJFYwnkjE

Wards definition is much more about the differences between the current implementation of the software and your understanding of the problem, particularly as your understanding changes over time.

He explicitly says that "tehcnical debt" is NOT an excuse to write known-to-be-poor code, which is why I disagree with the //TOBECLEANED approach.

This change in perspective shifts the point of view quite a bit. In some ways this problem defines a startup, your biggest problem is that you don't understand your problem. It's somewhat likely that you won't even have the same problem you'll successfully solve later. The first points are salient here, focus your engineering efforts on the things you don't understand yet, and the minimum support it needs to be viable. Shorten your feedback loop as you navigate the things you do not yet understand.

In this light, a startup is actively SEEKING technical debt, because it represents gaining understanding about a problem, and exploring that space quickly. This doesn't mean you have to "cut corners" and do things you know to be flawed, but it suggests focusing on small 'forays' into the unknown, gaining understanding quickly, and being willing to throw away your exploration for a new one if it isn't working. Then once you find a problem you start to understand and seems like a viable direction, you have a body of 'technical debt' that is the work you need to do to bring the software to your new growing understanding.

It seems like being willing to throw away the exploration if the direction isn't working out is a key advantage of a startup, along with the quick iteration times and lean support for explorations. This is why I dislike the suggestions of writing known-bad code. You're slowing your exploration down, but you aren't gaining understanding of the problem. It's junk debt, not technical debt. You can carefully minimize the supporting infrastructure your exploration requires, and avoid writing extra code, but you can't just slap it together.

It's not enough to flail around building as fast as you can, you have to deliberately learn and explore problems and understanding as you go, and evaluate which ones to put more exploration into and which to abandon. To me, this is the core work of a startup that differentiates it from established companies who are executing on a reasonably well understood problem. The (sometimes gradual) transition happens when you stop exploring, and start focusing on clearing the technical debt from your current exploration.

Thanks for sharing the article, I enjoyed engaging with these ideas!

What happens when the architect doesn't have the luxury of pushing back? As in, the business will make the architect's boss bend over if the architect says no?

I don't see technical debt as a problem, I see the lack of refactoring as part of a software teams culture as a problem.

Technical debt will be incurred, if you like it or not. Even if you spend a long time on architecture and abstractions, developing software is a process and the "fantastic" architecture you created a year ago is now hopelessly outdated. This happens because over time your insight into the problem domain increases which will give you a better understanding on how to approach the problem which will lead to better decisions on all sorts of things regarding the software you're writing.

Having refactoring as part of a software development team culture can help you manage technical debt. If you assume that the code itself isn't precious but the experience of the developers writing the code is, then you can move forward. You can have refactor sessions at regular intervals, e.g. every Friday afternoon or a whole Friday every fortnight, whatever works for you and your team.

In a refactor session the whole team can work together to make the software better; many eyes make all bugs shallow [1]. It also give an opportunity to create better synergy and banter between team members.

[1] https://en.wikipedia.org/wiki/Linus%27s_Law

not necessary. if you launch early a crappy feature with a ton of problems it is actually very harmful. time to market is just one dimension of a trade offs you need to balance if you want to succeed