5 ms·

I'm guessing by bad, you mean ugly. I'm fairly convinced there is no "good" code, or that it's such a minuscule subset that you'll never likely encounter it in

I'm guessing by bad, you mean ugly. I'm fairly convinced there is no "good" code, or that it's such a minuscule subset that you'll never likely encounter it in your career. Every year I look back on last years stuff I've written, and I can find ten ways to clean things up. In my opinion, if it works, and provides the utility it was designed to bring, then it doesn't matter. If it makes money, then who really cares!

nathan_long 8y ago
> In my opinion, if it works, and provides the utility it was designed to bring, then it doesn't matter. If it makes money, then who really cares! This makes sense. However, if the code 1) is hard to understand (according to the developers available) and change and 2) needs to be changed, it costs money. Eg, read about the expense banks are now incurring trying to maintain COBOL systems. Whether the code is "bad" is debatable. But the fact is that they have a hard time finding people who can work on it.
- overcast 8y ago
  Sure, but you're acting under the premise that "if we just did it 'right' the first time, we wouldn't have this mess". What I'm saying is that only under very few circumstances does it ever workout that way. Particularly with long standing systems and their software. It just builds over years, nothing you can really do about it.
  - nathan_long 8y ago
    > Sure, but you're acting under the premise that "if we just did it 'right' the first time, we wouldn't have this mess". I think you're right that every long-lived code base will have warts. And I don't think that means that the original builders were wrong-headed. But if you've got a decades-old system that nobody understands anymore, you've got a huge liability. You can't ship features to compete, you can't fix bugs, you can't comply with new regulations. You can't even rewrite confidently because you don't know what the old system does. There must be things you can do as a code base ages to keep it maintainable, allow incremental rewrites, etc.
    - ilovetux 8y ago
      You may not want to reinvent the wheel, but you have to change the tires.
koboll 8y ago
>I'm guessing by bad, you mean ugly. ... In my opinion, if it works, and provides the utility it was designed to bring, then it doesn't matter. If it makes money, then who really cares! "Ugly" is subjective; I'd define "bad code" as "difficult to reason about". If you're introducing someone new to the project, how long do they have to stare at it until they can grok it? Good code is code that makes sense, where things are documented and clearly named and encapsulated and have a flow that makes them understandable. This doesn't necessarily mean it isn't ugly. Often, it's uglier than "clever code" which does something succinctly but less obviously.
sooheon 8y ago
> If it makes money, then who really cares! If it makes money now, you might care about continuing to make money in the future. Being able to reason about and change your product should help with that, but so will more money to throw at it, as this thread shows.
deleted 8y ago
[deleted]

nathan_long 8y ago

> In my opinion, if it works, and provides the utility it was designed to bring, then it doesn't matter. If it makes money, then who really cares! This makes sense. However, if the code 1) is hard to understand (according to the developers available) and change and 2) needs to be changed, it costs money. Eg, read about the expense banks are now incurring trying to maintain COBOL systems. Whether the code is "bad" is debatable. But the fact is that they have a hard time finding people who can work on it.

overcast 8y ago
Sure, but you're acting under the premise that "if we just did it 'right' the first time, we wouldn't have this mess". What I'm saying is that only under very few circumstances does it ever workout that way. Particularly with long standing systems and their software. It just builds over years, nothing you can really do about it.
- nathan_long 8y ago
  > Sure, but you're acting under the premise that "if we just did it 'right' the first time, we wouldn't have this mess". I think you're right that every long-lived code base will have warts. And I don't think that means that the original builders were wrong-headed. But if you've got a decades-old system that nobody understands anymore, you've got a huge liability. You can't ship features to compete, you can't fix bugs, you can't comply with new regulations. You can't even rewrite confidently because you don't know what the old system does. There must be things you can do as a code base ages to keep it maintainable, allow incremental rewrites, etc.
  - ilovetux 8y ago
    You may not want to reinvent the wheel, but you have to change the tires.

koboll 8y ago

>I'm guessing by bad, you mean ugly. ... In my opinion, if it works, and provides the utility it was designed to bring, then it doesn't matter. If it makes money, then who really cares! "Ugly" is subjective; I'd define "bad code" as "difficult to reason about". If you're introducing someone new to the project, how long do they have to stare at it until they can grok it? Good code is code that makes sense, where things are documented and clearly named and encapsulated and have a flow that makes them understandable. This doesn't necessarily mean it isn't ugly. Often, it's uglier than "clever code" which does something succinctly but less obviously.

sooheon 8y ago

> If it makes money, then who really cares! If it makes money now, you might care about continuing to make money in the future. Being able to reason about and change your product should help with that, but so will more money to throw at it, as this thread shows.

deleted 8y ago

[deleted]