[MeinBlutIstBlau]

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.

[AllegedAlec]

> 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]

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.

[AllegedAlec]

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.

[kirse]

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.

[mzarate06]

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