In fact, once we started investing in that kind of development, we did do that with a successful new feature that we developed much more quickly than we could have in the past, and it's because of that success that leaders are finally starting to prioritize building standardized and reusable infrastructure.
EDIT: I think another way to say this is, once we knew our strengths and how we'd be successful in the future, we should have operationalized that and hardened it, so we'd have a sustainable advantage over competitors. Instead, we kept the "move fast, be flexible, and throw man-hours at problems" mentality too long, and it put us at risk.
Paying back the debt, he said, usually requires too much knowledge of a system to cycle teams in and out consistently enough to ensure everyone gets a piece of the new versus the old to keep them engaged.
Whether or not that was backed up by hard data, I'm not sure. It was an interesting angle I hadn't previously thought of though.
As someone who found themself in the "holding the fort" team, I can confirm that this analysis is at least anecdotally true, although the terms I preferred at the time for the two teams were Morlocks and Eloi.
Very true. The good performers will be “rewarded” doing the things that are really important: keeping things going. And then you have low performers and interns doing the new stuff.
In the long-term, I do think product-wide you always have teams at different levels of maturity. Some know more about the problems they're solving and how best to solve them, others know less. Some will move fast, some will build to last. The more a team knows about their problem, or the more a problem cuts across teams, the more I think they should build to last, so investment in those areas scales over a large group or important areas of the business.
There’s not an easy fix though, as most of the time I see orgs just punt at some point and allow the dev shop to write off all their tech debt by reassigning responsibility to an ops team.
While that's probably true, it's a difficult balance to know when exactly you should start moving back towards the better development practices. Too soon and you die, too late and you can no longer move because you're too inefficient.
This is a false dichotomy, and there is plenty of research (and experience) that shows shipping higher quality software actually takes less time and money.
I believe you when the business knows exactly what it's building. In the context of the article and the comment I was responding to, building high quality software wouldn't have helped them early on, thats kinda the whole point of tech debt and the discussion here. Knowing when is the right time to start changing the engineering culture and how easy (or hard) it is to do that.
My experience would suggest shipping higher quality software is a lot cheaper in the long run, but has up-front costs that often times startups can't afford.
They could have shipped higher quality software quicker by hiring 2 senior developers for similar cost.
Slapping it together pays off today but at the cost of acquiring a debt that costs lower average velocity and lower agility until its repaid.
A lot of small businesses make the decision to take on debt to move quickly at the beginning because the most important thing is initial growth and proving that you can actually make money.
It's hard to change culture; you tend to keep doing what worked before even if it's not optimal anymore. Yesterday's adaptive behavior is today's unfortunate practice.