Of course, having a measurement might help shine a spotlight on how things are getting worse, but I've never actually seen this happen. Perhaps others have a different experience?
You are making a good point about people not being around long term. In my company there are departments with high turnover and they tend to go for quick victories that are often costly in the long term. At the time this becomes clear the manager who made the previous has already been promoted somewhere else and the next guy will make another quick decision to fix the previous problem. Then this guy gets promoted too and the cycle continues.
Technical debt is really only a problem if you think long term.
Refactoring is quite literally the same thing as re-filing and reorganizing physical files. Under the academic definition of refactoring, the "contents" (the functionality) is not changing. Only the organization is changing.
After two years working on the new well tested, well written product, no one wanted the new .Net product, they stopped working on it and put everyone on the old PHP based product where there was a demand. Within 6 months after people’s vesting period elapsed, everyone (14+) developers left because no one wanted to do PHP.
Also, when he was a young hungry startup, he didn’t worry about “good practices”, but now that he was flush with cash and didn’t have to worry about going out of business, he could do things by the book.
I learned a few lessons over the years after that product and seeing how things really work - especially at smaller VC funded companies. No one cares about code quality, just growing features, acquiring customers, and the exit strategy.
It worked for Twitter....
You can keep velocity high on a badly run project for a couple years, but if your roadmap or business plan is long term, you will find that 5ings calcify before you’re ready for them. I always try to remind people that this is about the long term.
It’s also easier to grow and shrink a team when the code is Clean. But some of your coworkers won’t like the idea that they can be gotten rid of so easily. At the heart of its that’s the struggle. One or two experts on the system is enough to keep those people and their bosses fat and happy for quite a while.
In other words, what's the lesson here? Speed at all costs because you quickly figure out if the product is wanted? Or speed at all costs because bugs just don't matter?
Other projects not so much, especially in this day and age where rapid delivery and throwaway is actually an accepted form of SW development.
The fact that Agile and its ilk sprung up and mostly failed to address these issues shows how hard a problem this is.
There's also a fairly high bar for what gets marked as "Done", so the rework is a bit lower. I've been on stories where we spent as much time dealing with the architectural consequences of a new feature as we did on the visible bits.
Sometimes it can be hard. Especially in the anchorship role. I've once had to tie up an entire track of work to fix the tech debt equivalent of a toxic spill for weeks and weeks. It sucked, there was zero user-visible value gained, but it simply had to be done or we would suffer more and more.
I dunno if that's considered agile or not. At some level it doesn't bother me.
Programmers and our employers exhibit flocking behavior. See how Ruby on Rails brought so many people to the Ruby language. How Python had a similar surge earlier in the 00s, and later with the explosion of use (numpy and similar) in data science applications. Additionally, things like Ruby on Rails helped make the web application commonplace. See JavaScript and AJAX for that as well.
Perl established an effective code repository (CPAN) that enabled their userbase to grow via a similar flocking mechanism. Go has no central repository but has an easy to use mechanism for adding dependencies based on git repositories. That ease of access to published modules allows people to adopt the technology once a peer (someone working in a similar domain) publishes something. And it encourages people to contribute back in some fashion (publish new modules or update the existing ones). In Perl's case you saw a lot of people from outside IT making use of it (the same is now true for Python with data science) because the heavy lifting was done and they could focus on gluing things together.
Exploiting this flocking behavior, then, becomes important to anyone wanting to push a new technology out. Even if it's the best thing and would produce the best software ever, it won't always succeed on its own merits.
(random thoughts, no real thesis here)
Take an urn with green and red balls (or blue and orange, if you're colour-blind).
Pick out a ball. If it is red, put it back and replace a green ball with another red ball. If green, put it back and replace a red ball with a green.
Even starting with a perfect 50:50, and choosing completely randomly, a Polya process will eventually show that your probability of picking one colour becomes more or less certain. The urn "locks" into a particular path. While in theory it could return to 50:50 or swing back to the other colour, the odds of doing so rapidly become astronomical.
John Sterman's Business Dynamics: Systems Thinking and Modeling for a Complex World has a really excellent discussion. Worth looking for.
That particular model is interesting for what I described. Essentially, if someone wants to program they'll be drawn to one of the projects/people already out there which are already using some language. They'll then use the same language and become a person or produce a project that the next person may be drawn to. The original thing that drew them to the language is still there, and they're another point to draw someone else to the same language.
Thanks.
