16 ms·

So afraid to write bad, spaghetti code, I ended up writing no code at all. This thread made me realize that it's better to have a working profitable project wi

So afraid to write bad, spaghetti code, I ended up writing no code at all. This thread made me realize that it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns. Afraid of being judged for bad code, I could not start until I had the right architecture. I'm glad I read this. This is developers therapy.

deleted 5y ago
[deleted]
knome 5y ago
You sound like you should read this: [removed] apparently jwz decided not to be linked from here :/ there's an archive.org link below.
- GranPC 5y ago
  Heads up: jwz.org redirects Hacker News visitors (via "Referer") to an image of a slightly-hairy testicle sitting inside an egg cup. So maybe don't click the link at work.
  - AlexCoventry 5y ago
    Safe link: https://web.archive.org/web/20220318220659/https://www.jwz.org/doc/worse-is-better.html https://web.archive.org/web/20220318220659/https://www.jwz.o...
  - sillysaurusx 5y ago
    That’s friggin’ hilarious. What a boss.
  - Jaruzel 5y ago
    Ok, So I wanted to see it. Quick hack of the link tag in sibling comment, and this is what you see: NOT SFW! https://cdn.jwz.org/images/2016/hn.png https://cdn.jwz.org/images/2016/hn.png It's funny. Why does he hate us so?
- wincy 5y ago
  Uhh you should know that domain redirects traffic from hacker news to an offensive image.
- Jtsummers 5y ago
  https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html For future reference, a non-archive, non-jwz.org link. Straight from the source as that's the author's own site.
- albertzeyer 5y ago
  Put it like this: www.jwz.org/doc/worse-is-better.html Then just copy & paste it.
- baud147258 5y ago
  from the last time I saw that link on HN, opening it in a private browsing window avoid the redirection.
deleted 5y ago
[deleted]
khazhoux 5y ago
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking shortcuts. But in the end, even their code doesn't have the strongest tests, doesn't generalize for all the known use cases, etc. Team B never gets users or gains momentum, and their code+architecture was probably no better than Team A -- they just took 3x the time to get there.
- kolinko 5y ago
  +1 I had a lot of trouble trying to explain this to juniors. The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse than into a code that would be 10k lines in one file, but with a flat structure and less interdependency.
  - BurningFrog 5y ago
    > The most important things is to have code that is easy to refactor Very true. I'll just add that another most important thing is to actually take time to refactor, even when things are busy. I spend maybe 1/3 of my time refactoring, and that feels good.
    - jimbokun 5y ago
      I like to refactor once I have passing tests and before committing. Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.
      - 5y ago
Oras 5y ago
Been there. I worked in a company where we had a codebase like the one mentioned in the article and over the years we started developing microservices with 100% code coverage. The new shiny services took much longer to identify bugs and add new features due to the complexity of the design and endless interfaces.
29athrowaway 5y ago
Restaurant industry version: I was so afraid to cook in a dirty kitchen, I ended up not cooking at all. This thread made me realize that's better to sell food prepared on dirty surfaces with unrefrigerated ingredientes half-eaten by rodents and roaches that makes people sick, than fresh food prepared on clean surfaces with clean utensils. I'm glad I read this. This is a restaurant worker story. Construction industry version: I was so afraid of not using the right construction materials and not building code-compliant structures, I ended up not building at all. This thread made me realize that's better to sell houses with structural problems and low quality materials that will be unsafe to live in, than houses built according to code. I'm glad I read this. This is a builder story. In any other industry, a person would go to jail for saying that. You won't, because luckily for you, software development is not a regulated activity, and people with your mindset can make a happy living outside of jail. But hopefully one day some types of neglect in software development become illegal. "Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with.
- passivate 5y ago
  Your analogy is flawed. The CPU doesn't care at all about how or what code looks like, all the nice comments explaining what it does, nice naming conventions, whether its easy to understand or not. They have zero impact on the final compiled code. The executable ends up as a spaghetti of machine instructions with countless gotos in a single large file. Using bad ingredients in food, or poor quality materials in construction has tremendous impact on the final product. >"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with. Just calling code good or bad doesn't mean much - ultimately, results matter - if your code doesn't have tons of bugs, if your team can add features without any problems, if you can ship reasonably on time, if your product delivers value to the end user, etc - then you have succeeded. It doesn't matter what outsiders think about the code or what labels people give. Its best to ignore them and continue doing good work.
  - 5y ago
bpicolo 5y ago
> it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns. A lot of businesses were built on PHP this way
squeaky-clean 5y ago
The Player controller from the game Celeste is a single 5600 line file that includes things like systems only used in the tutorial. I honestly don't think it's as bad as some of the criticism it got when the code was released makes it seem, but it certainly could be better looking code. But ultimately, Maddy Thorson isn't selling a block of code. They're selling a game and it has extremely satisfying control of the character. And that's all that really matters for a player controller. Maybe better organization and design patterns could have made it faster to develop? But I don't believe it would. But also the type of product does matter for this. Celeste had 2 programmers so a lot of the things necessary for a team of 100 devs would just be harmful. If you're making a library/framework to be used and modded by others, architecture matters a lot more. If you're designing an enterprise application that you know will need business logic customizations for 25 business customers it matters more. It's all about knowing the scope of your project. But also until you start getting that many customers, maybe the unsustainable method is what will allow you to reach those first few sales more quickly to be able to stay in business long enough to be bit by the technical debt.
- cyber_kinetist 5y ago
  I remember sharing that Player.cs code from Celeste in the gamedev subreddit, and getting all kinds of weird novice comments about how the code doesn't adhere to 'OOP Principles' or 'there isn't any unit tests' or 'you should split it into multiple files with 100 lines each' or 'you should use an ECS to make a real game'. Laster on Noel Berry did give a response explaining the various design choices behind their code: https://github.com/NoelFB/Celeste/tree/master/Source/Player https://github.com/NoelFB/Celeste/tree/master/Source/Player Anyways, kudos to the team sharing their code even if it's a bit messy.
  - squeaky-clean 5y ago
    I hadn't seen the new Readme update (even though I Googled the repo again to link the cs file lol). Thanks!
heywire 5y ago
I am part of a small team that maintains a legacy point of sale system that is still used by thousands of stores around the world. It started life as a DOS application written in C with some ASM bits, and has since accumulated some C++ and C#. There are functions over 5000 lines long. Files over 50000. Global all over the place. It can be a challenge sometimes, but after almost 30 years, it still brings in millions of dollars a year in maintenance and enhancements, and still processes millions of transactions for those retailers.
- mbrodersen 5y ago
  The world runs on software like that. Hard to maintain “crappy” code that makes $ beats clean pure “perfect” code that makes zero $ every time.
zem 5y ago
let me recommend one of my favourite programming blog posts: https://prog21.dadgum.com/21.html https://prog21.dadgum.com/21.html
wonderwonder 5y ago
Getting something working and out there is 90% of the battle, especially on small or single person teams. I wrote a saas php app with vanilla html and JS that ran without issue for 8.5 years for a fortune 1000 company. About twice a year I would return to it to add or modify a feature and I had no idea how a lot of it worked and even had duplicated or redundant files that I was too afraid to delete. It worked though and I got paid every month for a very long time. Sometimes delivering a product is all it takes and getting trapped in delivering 'clean' code is just a blocker. Not often, but sometimes :)
- nukst 5y ago
  I want to hear more from you.
2143 5y ago
+100 I'm so afraid of creating programs in languages that don't enforce a structure at all, even though I know how to write everything from scratch make it work. If it's some framework, then it'll already be structured somewhat. In the rare event that I do create something with no frameworks, I ensure that there aren't much global variables.
leetcrew 5y ago
happy medium: write shitty code with strong API boundaries. at least the damage is localized and every so often you can go back and clean up or replace components independently. or more likely, just leave it that way and make more poorly implemented features that make money.

deleted 5y ago

[deleted]

knome 5y ago

You sound like you should read this: [removed] apparently jwz decided not to be linked from here :/ there's an archive.org link below.

GranPC 5y ago
Heads up: jwz.org redirects Hacker News visitors (via "Referer") to an image of a slightly-hairy testicle sitting inside an egg cup. So maybe don't click the link at work.
- AlexCoventry 5y ago
  Safe link: https://web.archive.org/web/20220318220659/https://www.jwz.org/doc/worse-is-better.html https://web.archive.org/web/20220318220659/https://www.jwz.o...
- sillysaurusx 5y ago
  That’s friggin’ hilarious. What a boss.
- Jaruzel 5y ago
  Ok, So I wanted to see it. Quick hack of the link tag in sibling comment, and this is what you see: NOT SFW! https://cdn.jwz.org/images/2016/hn.png https://cdn.jwz.org/images/2016/hn.png It's funny. Why does he hate us so?
wincy 5y ago
Uhh you should know that domain redirects traffic from hacker news to an offensive image.
Jtsummers 5y ago
https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html For future reference, a non-archive, non-jwz.org link. Straight from the source as that's the author's own site.
albertzeyer 5y ago
Put it like this: www.jwz.org/doc/worse-is-better.html Then just copy & paste it.
baud147258 5y ago
from the last time I saw that link on HN, opening it in a private browsing window avoid the redirection.

deleted 5y ago

[deleted]

khazhoux 5y ago

I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking shortcuts. But in the end, even their code doesn't have the strongest tests, doesn't generalize for all the known use cases, etc. Team B never gets users or gains momentum, and their code+architecture was probably no better than Team A -- they just took 3x the time to get there.

kolinko 5y ago
+1 I had a lot of trouble trying to explain this to juniors. The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse than into a code that would be 10k lines in one file, but with a flat structure and less interdependency.
- BurningFrog 5y ago
  > The most important things is to have code that is easy to refactor Very true. I'll just add that another most important thing is to actually take time to refactor, even when things are busy. I spend maybe 1/3 of my time refactoring, and that feels good.
  - jimbokun 5y ago
    I like to refactor once I have passing tests and before committing. Once you know it works take a minute to clean up and make the changes fit your preferred style, extract repeated code into shared methods, comment the tricky bits, etc.
    - 5y ago

Oras 5y ago

Been there. I worked in a company where we had a codebase like the one mentioned in the article and over the years we started developing microservices with 100% code coverage. The new shiny services took much longer to identify bugs and add new features due to the complexity of the design and endless interfaces.

29athrowaway 5y ago

Restaurant industry version: I was so afraid to cook in a dirty kitchen, I ended up not cooking at all. This thread made me realize that's better to sell food prepared on dirty surfaces with unrefrigerated ingredientes half-eaten by rodents and roaches that makes people sick, than fresh food prepared on clean surfaces with clean utensils. I'm glad I read this. This is a restaurant worker story. Construction industry version: I was so afraid of not using the right construction materials and not building code-compliant structures, I ended up not building at all. This thread made me realize that's better to sell houses with structural problems and low quality materials that will be unsafe to live in, than houses built according to code. I'm glad I read this. This is a builder story. In any other industry, a person would go to jail for saying that. You won't, because luckily for you, software development is not a regulated activity, and people with your mindset can make a happy living outside of jail. But hopefully one day some types of neglect in software development become illegal. "Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with.

passivate 5y ago
Your analogy is flawed. The CPU doesn't care at all about how or what code looks like, all the nice comments explaining what it does, nice naming conventions, whether its easy to understand or not. They have zero impact on the final compiled code. The executable ends up as a spaghetti of machine instructions with countless gotos in a single large file. Using bad ingredients in food, or poor quality materials in construction has tremendous impact on the final product. >"Better is the enemy of the worse" is no excuse to have spaghetti code, or 50,000 lines of code files. It means that good is sometimes more convenient than perfect. Spaghetti code is not good to begin with. Just calling code good or bad doesn't mean much - ultimately, results matter - if your code doesn't have tons of bugs, if your team can add features without any problems, if you can ship reasonably on time, if your product delivers value to the end user, etc - then you have succeeded. It doesn't matter what outsiders think about the code or what labels people give. Its best to ignore them and continue doing good work.
- 5y ago

bpicolo 5y ago

> it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns. A lot of businesses were built on PHP this way

squeaky-clean 5y ago

The Player controller from the game Celeste is a single 5600 line file that includes things like systems only used in the tutorial. I honestly don't think it's as bad as some of the criticism it got when the code was released makes it seem, but it certainly could be better looking code. But ultimately, Maddy Thorson isn't selling a block of code. They're selling a game and it has extremely satisfying control of the character. And that's all that really matters for a player controller. Maybe better organization and design patterns could have made it faster to develop? But I don't believe it would. But also the type of product does matter for this. Celeste had 2 programmers so a lot of the things necessary for a team of 100 devs would just be harmful. If you're making a library/framework to be used and modded by others, architecture matters a lot more. If you're designing an enterprise application that you know will need business logic customizations for 25 business customers it matters more. It's all about knowing the scope of your project. But also until you start getting that many customers, maybe the unsustainable method is what will allow you to reach those first few sales more quickly to be able to stay in business long enough to be bit by the technical debt.

cyber_kinetist 5y ago
I remember sharing that Player.cs code from Celeste in the gamedev subreddit, and getting all kinds of weird novice comments about how the code doesn't adhere to 'OOP Principles' or 'there isn't any unit tests' or 'you should split it into multiple files with 100 lines each' or 'you should use an ECS to make a real game'. Laster on Noel Berry did give a response explaining the various design choices behind their code: https://github.com/NoelFB/Celeste/tree/master/Source/Player https://github.com/NoelFB/Celeste/tree/master/Source/Player Anyways, kudos to the team sharing their code even if it's a bit messy.
- squeaky-clean 5y ago
  I hadn't seen the new Readme update (even though I Googled the repo again to link the cs file lol). Thanks!

heywire 5y ago

I am part of a small team that maintains a legacy point of sale system that is still used by thousands of stores around the world. It started life as a DOS application written in C with some ASM bits, and has since accumulated some C++ and C#. There are functions over 5000 lines long. Files over 50000. Global all over the place. It can be a challenge sometimes, but after almost 30 years, it still brings in millions of dollars a year in maintenance and enhancements, and still processes millions of transactions for those retailers.

mbrodersen 5y ago
The world runs on software like that. Hard to maintain “crappy” code that makes $ beats clean pure “perfect” code that makes zero $ every time.

zem 5y ago

let me recommend one of my favourite programming blog posts: https://prog21.dadgum.com/21.html https://prog21.dadgum.com/21.html

wonderwonder 5y ago

Getting something working and out there is 90% of the battle, especially on small or single person teams. I wrote a saas php app with vanilla html and JS that ran without issue for 8.5 years for a fortune 1000 company. About twice a year I would return to it to add or modify a feature and I had no idea how a lot of it worked and even had duplicated or redundant files that I was too afraid to delete. It worked though and I got paid every month for a very long time. Sometimes delivering a product is all it takes and getting trapped in delivering 'clean' code is just a blocker. Not often, but sometimes :)

nukst 5y ago
I want to hear more from you.

2143 5y ago

+100 I'm so afraid of creating programs in languages that don't enforce a structure at all, even though I know how to write everything from scratch make it work. If it's some framework, then it'll already be structured somewhat. In the rare event that I do create something with no frameworks, I ensure that there aren't much global variables.

leetcrew 5y ago

happy medium: write shitty code with strong API boundaries. at least the damage is localized and every so often you can go back and clean up or replace components independently. or more likely, just leave it that way and make more poorly implemented features that make money.