4 ms·

Technical debt within a working codebase is a much, much better problem to have than not being able to launch or even demonstrate your product. It's really over

Technical debt within a working codebase is a much, much better problem to have than not being able to launch or even demonstrate your product. It's really overrated. I left a huge pile of it in my previous company (amassed over 18 years of programming in Perl) and guess what: it's doing great, more profitable than ever before. The code has been slowly enhanced, some of it refactored. Code quality (as in "beauty", not correctness) is the least of your problems in a startup, although it will look bigger for those who have to work on it (pity them but don't overemphasize).

Ma8ee 8y ago
Yes, but the other side of the coin is having a codebase that is so old and such a mess that it can't be changed or upgraded without a tremendous cost. I have worked for a company that eventually went down because there was absolutely no separation between business logic and user interface. When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. Either extreme is stupid. Of course you have to ship. And in early stages it often makes sense to accrue debt to get fast to the market. But of course you also have to be able to be nimble and move fast even after two years and five. You can't do that if all your resources are tied up in interest payments.
- lazyjones 8y ago
  > When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. Kinda obvious what their actual mistake was then... > I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. I see a pattern there. > But of course you also have to be able to be nimble and move fast even after two years and five. You can also go broke while chasing this illusion, twice. Whether as startup or established company with a "big ball of mud" codebase. I'd rather tackle the "no one wants to pay" problem in a profitable company than a complete rewrite, or even trying to boot up a new company while, in addition to all the other problems involved, trying to write "beautiful code", thank you.
  - Ma8ee 8y ago
    I don't know anything about you personally, but my experience with people that argue like you is that they don't understand or don't care about maintainable code at all. So every time someone tries to argue for something like best practices they get shouted down as completely unpractical and out of touch. The problem is that the people doing the shouting is often the ones that produces code at high speed. They are productive while everyone else has to clean up their mess. Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just don't go along very often.
pyrale 8y ago
This may be hard to hear depending on your experience, but some companies need to develop code over decades. When the problem is not money but ability to maintain, delivering a poc one month earlier is not always a competitive edge.
rtpg 8y ago
Technical debt isn't an all or nothing thing. It can just slow you down _a bit_. But if you accumulate enough now things that should take an hour take 2 hours. or 4 hours. Or 3 days! The non-refutable answer is you should spend an adequate amount of time thinking about stuff before doing them. Anecdotally I've found that people are not very good at thinking well while simultaneously coding, so thinking a bit before opening the code browser works pretty well Being able to distinguish avoidable technical debt and reasonable tradeoffs at the time can save you a hell of a lot of time. And yeah working in messy codebases suck! But more importantly it can cause people to lose time they could spend working on more features and shipping stuff
peteradio 8y ago
Is there no spectrum with you? Do you see any need for architecture? That is the base of the dreaded beautiful code. Stay far away!!!

Ma8ee 8y ago

Yes, but the other side of the coin is having a codebase that is so old and such a mess that it can't be changed or upgraded without a tremendous cost. I have worked for a company that eventually went down because there was absolutely no separation between business logic and user interface. When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. Either extreme is stupid. Of course you have to ship. And in early stages it often makes sense to accrue debt to get fast to the market. But of course you also have to be able to be nimble and move fast even after two years and five. You can't do that if all your resources are tied up in interest payments.

lazyjones 8y ago
> When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. Kinda obvious what their actual mistake was then... > I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. I see a pattern there. > But of course you also have to be able to be nimble and move fast even after two years and five. You can also go broke while chasing this illusion, twice. Whether as startup or established company with a "big ball of mud" codebase. I'd rather tackle the "no one wants to pay" problem in a profitable company than a complete rewrite, or even trying to boot up a new company while, in addition to all the other problems involved, trying to write "beautiful code", thank you.
- Ma8ee 8y ago
  I don't know anything about you personally, but my experience with people that argue like you is that they don't understand or don't care about maintainable code at all. So every time someone tries to argue for something like best practices they get shouted down as completely unpractical and out of touch. The problem is that the people doing the shouting is often the ones that produces code at high speed. They are productive while everyone else has to clean up their mess. Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just don't go along very often.

pyrale 8y ago

This may be hard to hear depending on your experience, but some companies need to develop code over decades. When the problem is not money but ability to maintain, delivering a poc one month earlier is not always a competitive edge.

rtpg 8y ago

Technical debt isn't an all or nothing thing. It can just slow you down _a bit_. But if you accumulate enough now things that should take an hour take 2 hours. or 4 hours. Or 3 days! The non-refutable answer is you should spend an adequate amount of time thinking about stuff before doing them. Anecdotally I've found that people are not very good at thinking well while simultaneously coding, so thinking a bit before opening the code browser works pretty well Being able to distinguish avoidable technical debt and reasonable tradeoffs at the time can save you a hell of a lot of time. And yeah working in messy codebases suck! But more importantly it can cause people to lose time they could spend working on more features and shipping stuff

peteradio 8y ago

Is there no spectrum with you? Do you see any need for architecture? That is the base of the dreaded beautiful code. Stay far away!!!