7 ms·

I think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivi

I think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.

varjag 8y ago
Take a "perfectionist", and you end up having all that atop of nothing actually yet running in production.
lazyjones 8y ago
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!!!
scarejunba 8y ago
It actually doesn't matter because you can always rewrite a working product. If you never have a product nothing helps. In the end, all code is debt. The only thing is whether you earned anything from the debt. If you never earn anything it doesn't matter that you didn't take on that much debt.
- extra_rice 8y ago
  > It actually doesn't matter because you can always rewrite a working product. False. Sure, technically, this is true, but in practice there are lots of variables at play here. Who is going to pay for the rewrite? Is the company profitable enough to do that while maintaining legacy code for current users to use? I'm not saying the only way to develop a product is to get it right the first time, but ideally, organisations shouldn't have to pay for the same product twice.
soup10 8y ago
In my 20 years of programming i've never heard of a well architectured codebase that is cleanly written, problem free, future proof and a joy to maintain.
- arethuza 8y ago
  I've heard of plenty (mostly in the future tense) - reality often seems somewhat different.
- collyw 8y ago
  Sure, but some codebases are way worse than others.
- adamlett 8y ago
  Lots of open source projects are well architected and cleanly written[1]. Demanding that they also be problem free, or future proof, is a red herring. I've never heard any proponent of clean code claim that these are side effects of clean code. [1] Examples I can think of off the top of my head: KHTML/Webkit, Hanami.rb, the Go standard library, sqlite...
konamicode 8y ago
> At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code. Ousterhout uses the term "tactical tornado"s, which I quite like (source: https://twitter.com/johofer/status/1035442341199446017 https://twitter.com/johofer/status/1035442341199446017 apologies I don't have a better source handy).
mpartel 8y ago
Moreover, I think there's an 80/20-ish sweet spot. With an attitude of moderation, you can keep a brisk pace and achieve a pretty clean codebase with little extra effort. It seems best to defer architecting just long enough to see that some component is becoming problematic, but not much longer. Do it too early and you waste effort. Do it too late and you have a much larger mess to clean up.

varjag 8y ago

Take a "perfectionist", and you end up having all that atop of nothing actually yet running in production.

lazyjones 8y ago

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

scarejunba 8y ago

It actually doesn't matter because you can always rewrite a working product. If you never have a product nothing helps. In the end, all code is debt. The only thing is whether you earned anything from the debt. If you never earn anything it doesn't matter that you didn't take on that much debt.

extra_rice 8y ago
> It actually doesn't matter because you can always rewrite a working product. False. Sure, technically, this is true, but in practice there are lots of variables at play here. Who is going to pay for the rewrite? Is the company profitable enough to do that while maintaining legacy code for current users to use? I'm not saying the only way to develop a product is to get it right the first time, but ideally, organisations shouldn't have to pay for the same product twice.

soup10 8y ago

In my 20 years of programming i've never heard of a well architectured codebase that is cleanly written, problem free, future proof and a joy to maintain.

arethuza 8y ago
I've heard of plenty (mostly in the future tense) - reality often seems somewhat different.
collyw 8y ago
Sure, but some codebases are way worse than others.
adamlett 8y ago
Lots of open source projects are well architected and cleanly written[1]. Demanding that they also be problem free, or future proof, is a red herring. I've never heard any proponent of clean code claim that these are side effects of clean code. [1] Examples I can think of off the top of my head: KHTML/Webkit, Hanami.rb, the Go standard library, sqlite...

konamicode 8y ago

> At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code. Ousterhout uses the term "tactical tornado"s, which I quite like (source: https://twitter.com/johofer/status/1035442341199446017 https://twitter.com/johofer/status/1035442341199446017 apologies I don't have a better source handy).

mpartel 8y ago

Moreover, I think there's an 80/20-ish sweet spot. With an attitude of moderation, you can keep a brisk pace and achieve a pretty clean codebase with little extra effort. It seems best to defer architecting just long enough to see that some component is becoming problematic, but not much longer. Do it too early and you waste effort. Do it too late and you have a much larger mess to clean up.