I’ve been in the software industry for over 16 years now. From my experiences, it seems like it’s always more difficult to get investment in addressing technical debt. First, many developers, me included, aren’t always the best at communicating the value investing in scoped improvements projects brings to the business. I’ve improved at communicating the value upwards over time. Executives don’t see software the same way engineers do and you need to learn to speak their language. Second, investing in a new feature or project can easily become a more desirable investment because it’s new, exciting, and potentially a differentiator. The best way to get investment to address tech debt seems to have a crisis unless organizations have a deliberate, systematic process the helps avoid accumulating too much debt.
You’ll never get a chance to refactor code if you ask for it. The business folks and users themselves don’t care what the code looks like. They don’t care if there are 11 different micro services and a hodgepodge of pudding holding it together. They never will.
Don’t waste time trying to write a better pitch. You won’t get to halt development to essentially deliver nothing as far as they’re concerned.
Write code that is meant to be deleted. Refactor mercilessly. If code looks like crap but had sufficient tests, rewrite the code. If the tests are crap write better tests. Then rewrite the code.
Don’t ship the first thing that works on your PR/MR. Take some time to compress that code down, get rid of any cruft, and make sure it’s easily replaceable. You never know what new requirements or changes in specs will bring you back to this code in the future. Make it easy to replace (in the worst case scenario) if you needed to.
Wrap code that isn’t under test in a good API. Make the API call into the bad code. Write good tests for the API. Replace the bad code paths as you go.
Part of our job is writing maintainable, stable, and reliable code.
But if they’re deliberately asking you to cut corners, start documenting things.
There’s a time and place for “good enough,” and then there’s straight up neglect. Avoid the latter.
I've been trying to push the phrase "Design for deletion", as a contrast to designing for a flexibility or extensibility.
I used to try to predict far-ahead feature or architectural needs, but more often than not they either never materialized or appeared with some unforseen incompatible quirk.
Instead, I want to ensure that whatever I write can be ruthlessly ripped out and replaced with a minimum of pain.
It's not quite the same as a blanket priority on decoupling code, since statically-checkable compile-time coupling Isn't the big problem, and might even be preferred over runtime plugin architecture astronautics.
I'm a huge fan of this "stay in your lane and keep your house clean" philosophy. IME I just obsess over the details of whatever job I have at any time. People don't even really care what you're doing, all they see is someone that gives a damn in a sea of apathy. They'll promote you the first chance they get. I promise.
This has worked for me since I was taking out the trash at a fast food restaurant all the way to leadership positions at Fortune 50.
> many developers, me included, aren’t always the best at communicating the value investing in scoped improvements projects brings to the business
While that is true, I don’t think it could be a communication-from-developers problem. Tech debt impairs development speed and causes small irritations in the every-day use of the product.
In my experience, what works is extreme ownership. Someone with agency has to care.
