How I Learned to Stop Worrying and Love Tech Debt(heap.io)
heap.io
How I Learned to Stop Worrying and Love Tech Debt
https://heap.io/blog/how-i-learned-to-stop-worrying-and-love-tech-debt
13 comments
My lead taught me at my internship that "working code is better than no code. As you get better and come back to it, your working code will eventually be clean code." We have a super small team so my lead can easily say those things, but I have learned to agree. Get the product to work. Who cares if you've got a function with inefficient algorithms right now. You've got a deadline and something that works fine. You can just throw a TODO on there, set a calendar reminder, and check back later. It's not pretty and yeah it may be like three nested for loops, recursion, and a really indented mess, but so what. It works, and you can follow it. In the business world, all that matters is results. When management is happy, you can go back and fix that thing you now have some extra time for. If not, just make note of it so the next person coming in is aware it's bad code. No harm no foul. It just comes with the territory.
> working code is better than no code. As you get better and come back to it, your working code will eventually be clean code
That only works under the assumption that you have time to come back to it. I've also seen cases where you just get 15 years of cruft, good intentions and bad implementations, at which point people never want to touch it again, because the last time they did they accidentaly broke a client's system.
That only works under the assumption that you have time to come back to it. I've also seen cases where you just get 15 years of cruft, good intentions and bad implementations, at which point people never want to touch it again, because the last time they did they accidentaly broke a client's system.
I noticed the warning sign for such accumulated crust and culture, is usually a exponential dev team growth curve.
We just need 4 new devs this year and 8 new devs next year.
All that while the actual product is at linear growth.
Yes, it works, but its foreseeable that it will end working in n-years were dev-team size and cost is bigger then the whole money the product earned.
A warning sign isn't actionable perse though. All of our developers know that we're heading for a disaster, be it in a decade or 2 years. But given that we're busy a 100% of the time implementing new features for existing customers or setting up our software for new ones. There's no time for us to start fixing this mess, and even if we did: that doesn't pay the bills.
It's a balance. There's also the saying that "the prototype usually becomes the product", which means that by the time the team has made all those tech debt mini-concessions along the way and have allowed engineers to sneak through pull-requests with zero discipline (it works just send it bro), they've basically sacrificed any sort of compound interest that could have been gained by teaching the team the correct fundamentals from the beginning.
There's a 6-month startup phase in just about every SW project I've led that sets a strong course for the lifetime of the project that is awfully hard to correct, both for better or for worse. My advice is always suck it up early and collect the dividends down the road.
There's a 6-month startup phase in just about every SW project I've led that sets a strong course for the lifetime of the project that is awfully hard to correct, both for better or for worse. My advice is always suck it up early and collect the dividends down the road.
I typically sum this up with a phrase Kent Beck made popular:
Make it work, make it right, make it fast.
I've shared that with a couple teams in the past, and it always catches on.
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Make it work, make it right, make it fast.
I've shared that with a couple teams in the past, and it always catches on.
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Off topic: Everyone using “How I learned to stop worrying and…” for their titles is getting really stale.
Start by making your plan digestible. My favorite quote from the article.
Even though the future is unpredictable, we can at least be clear on where we are going.
Even though the future is unpredictable, we can at least be clear on where we are going.
Very good article!
I didn't read the whole article, and that's certainly one way of looking at it. Here is another. That lack of maintainability and flexibility in a core codebase will leave your system in what's essentially cement shoes. Your team will have painted themselves in a corner and things that take hours or days in a nimble team with a nimble codebase will take weeks or months. That's fine most of the time if you're established in your industry, raking in the cash. That is until your industry pivots, and it will pivot. When it does, your team will not be able to pivot and will be included in the "out of business" companies mentioned above.
You don't have to have every algorithm tuned to computer's science's optimal guidance, you just have to have a maintainable system that can adjust to the business environment. I've been at plenty of large companies that can't adapt by adding new features because all the original programmers left, and management is to scared to touch the system for good reason, the codebase is a horrendous, unmaintainable mess.