The Way We Look at Technical Debt Is Wrong

And it wasn't just crappy web apps or throwaway MVP stuff. The first one was in medical systems, where the suits figured we had a 6 month lead on our closest competitor, the other was in consumer electronics (navigation devices), in the time that competition was still stiff in that sector.

In both cases it was decided that releasing something was more important, knowing full well that we had to pay the cost later. Of course not everyone agreed with it, since no one likes having to work with legacy crap, and everyone and their mother always wants to refactor all the things, but guess what: code quality is not the goal of your company, making money is.

1/ Poor code =/= technical debt. Far too often, poor code masquerades as "technical debt"

2/ Good engineers do the right thing which is always a judgment call based on circumstance & culture.

3/ Take guidance from your best engineers, and find a way for the business to adapt. Much easier to change the sales deck or pricing today, much harder to overcome bad technical decisions. No one ever said "I never knew that sales deck or pricing would last this long" but many say this about software. Be super careful & deliberate.

4/ Build things that are simple (not easy), and respond to demand. Focus on movability & robustness, not "perfect" design.

Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I say.

It happens with jr. devs, too. They want to use a singleton to solve a problem, or they want to forgo using any sort of referential constraints in their schemas.

Of course, the PMs and jr. devs always choose the shortcuts. I help them both pick up the pieces afterwards, but I never work overtime for it. The point is to make it clear that nobody other than themselves is responsible for their own mistakes. They led us into the mess, they can lead us out.

After that, everyone seems to get along a lot better and everyone seems super keen on having discussions about the "right" way to do things and how to fit things into the current state of the project correctly.

My opinion is that whether it's programming or general white-collar work, most cases of doing it "the right way" vs. "the dirty way" tend to be about investing the "certainty" of lost time immediately for the "promise" of savings.

For some things, the tradeoff is pretty decent (taking time to improve core knowledge or relevant skills that are related to goals).

But for a quickly growing company, how many situations are there where a "hack it out" fix that costs time in the long run is a net win in opportunity cost and hence long-term value?

If a shortcut that will cause you headaches in 9-18 months also allows you to add critical features at an accelerated pace for the next 6 months, is it: (1) inefficient because you net lose man-hours or (2) efficient (a) maximizes your near-term growth trajectory, (b) thereby increasing potential access to resources and hence long-term growth

To be clear, I do agree with your statements about shortcuts usually not saving time especially when you deal with teams/setting standards.

My point is more that while time saved/lost is easier to mentally calculate, it alone is not really what's driving value in many situations.

There's also the inherent problem of using qualitative terms that mean different things to different people.

But hey, that's part of the fun on the internet.

I think developers, including myself, like to get things right before launch because fixing it after launch is harder, if not impossible once other emergency/technical debt comes in and starts layering on top of that debt.

If this goes on for 1-2 cycles, before long your app, backend and internals look like a shanty town that no developer wants to enter.

Sometimes I wish code was visual like buildings, you could more easily see quality that way. Mostly though you have to believe in your developers/engineers that what they are building is a mansion/building you want not a shanty town dwelling that is held up on duct tape and silly putty, yet the technical pressure/debt put on is largely coming from someone who can't see the visual representation of the system.

Developers can only be MacGyver for so many release cycles before instability strikes the system down if management is not careful.

There will always be some amount of technical debt but developers do love to get things done and out the door as fast as possible. We like to do so with a minimum amount of technical debt as it is a constant battle against time/market/cost with quality.