How I Learned to Stop Worrying and Love Tech Debt

https://heap.io/blog/how-i-learned-to-stop-worrying-and-love-tech-debt

by df07 • 5 years ago

31 13 5 years ago

heap.io

evilkillerwhale• 5 years ago

Very good article!

matttrotter• 5 years ago

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.

MeinBlutIstBlau• 5 years ago

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.

kirse• 5 years ago

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.

AllegedAlec2• 5 years ago

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.

uCantCauseUCant• 5 years ago

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.

mzarate06• 5 years ago

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

Clubber• 5 years ago

“If it makes you feel any better, there's a way in which having a big mess is a sign of success. The reason your competitors don't have messes is that they went out of business. You won, and your prize is an application that betrays the ravages of time.”

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.

sib301• 5 years ago

Off topic: Everyone using “How I learned to stop worrying and…” for their titles is getting really stale.

jcelerier• 5 years ago

"How I Learned to Stop Worrying and..." Titles Considered Harmful

lootsauce• 5 years ago

AFAIK HILTSWAL is not a thing but IMHO it should be.

coolgeek• 5 years ago

Gentlemen - you can't fight in here! This is the War Room!

How I Learned to Stop Worrying and Love Tech Debt

Related Stories