4 ms·

It's not so much that software is "cheap" (it's not, software is notoriously expensive) but that it's incrementally improvable. If I build a house with a bad f

It's not so much that software is "cheap" (it's not, software is notoriously expensive) but that it's incrementally improvable. If I build a house with a bad frame, it's really hard to make it better over time. If I build a quick MVP, I can easily incrementally improve it.

jameshart 10y ago
Today's "quick MVP we can incrementally improve" is tomorrow's "unmaintainable legacy codebase." But sure, it'll be different this time.
- morgante 10y ago
  Legacy codebases make money. The engineer anxiety about them is myopic and ignorant of business realities. If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. The fact that a codebase has existed long enough to become "legacy" means it did a good enough job to stay alive.
  - onion2k 10y ago
    The engineer anxiety about them is myopic and ignorant of business realities. I don't think that's fair to a large number of engineers. We know that code gets loaded with technical debt and we know that we can't spend time fixing it because of "business realities". That doesn't mean it isn't a problem for us though. Anyone whose had to maintain a codebase that's years old and riddled with undocumented and untested "features" suffers for it. Old code is a source of stress and anxiety. It might make money, but that isn't a reason to think it's not an issue.
    - matt_wulfeck 10y ago
      Can you name a single trade where that's not also true? Keeping any mechanical thing running for years takes a lot of monkey-patching and duct tape. Technical debt in software engineering is not the exception. It's typical.
  - jasonthevillain 10y ago
    > The engineer anxiety about them is myopic and ignorant of business realities. Far from. The worry is not "this code is old." Plenty of old code (especially boring old code) is cranking along just fine. The worry is that if an old, abstruse system stops working or has a critical security bug, there's a real risk that nobody will be able to put the fire out.
  - khedoros1 10y ago
    > If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. Well, yeah, for the first version. But when is the first version also the last one? Not in many good situations. Crap that doesn't immediately collapse under its own weight will probably immediately collapse as soon as you add more weight to it in version 2. A lack of anxiety about the structure of the product is myopic and ignorant of engineering realities. There's got to be a balance. Too little anxiety, and you lose customers to competitors that spent more time to build a quality product, structured so that it's easier to grow. Too much anxiety, and you're in a "perfect is the enemy of good" situation, and you'll lose customers to competitors that were able to iterate faster and with a proper balance.
onion2k 10y ago
If I build a quick MVP, I can easily incrementally improve it. But you won't. Even if you want to, the client won't pay you to because all the client sees a working solution, so you never get the chance to. That's the problem the author is highlighting.
- morgante 10y ago
  Sure I will. Most products have continual work done on them. Code "quality" (whatever bullshit metric you use for that) is not the only metric of improvement. In fact, it's probably the least important metric to optimize over time.
  - onion2k 10y ago
    Most products have continual work done on them. Usually that's new features and bug fixes. It's very rare to find a client who'll happily pay for refactoring. If you're in a job where you get time for that you should consider yourself very lucky indeed. EDIT: For what it's worth, I agree with your point about code quality. What's 'beautiful' now is only 'perfect' in the frame of the current feature set. It might be horrible if the next feature that comes along changes things dramatically. I'm very much of the opinion that "good is better than perfect", just with the addendum that the code at least has to be good. Bad code is just bad.
bsg75 10y ago
"Just ship it, we can iron out the bugs later" - later never comes because that cycle repeats ad nauseam.

jameshart 10y ago

Today's "quick MVP we can incrementally improve" is tomorrow's "unmaintainable legacy codebase." But sure, it'll be different this time.

morgante 10y ago
Legacy codebases make money. The engineer anxiety about them is myopic and ignorant of business realities. If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. The fact that a codebase has existed long enough to become "legacy" means it did a good enough job to stay alive.
- onion2k 10y ago
  The engineer anxiety about them is myopic and ignorant of business realities. I don't think that's fair to a large number of engineers. We know that code gets loaded with technical debt and we know that we can't spend time fixing it because of "business realities". That doesn't mean it isn't a problem for us though. Anyone whose had to maintain a codebase that's years old and riddled with undocumented and untested "features" suffers for it. Old code is a source of stress and anxiety. It might make money, but that isn't a reason to think it's not an issue.
  - matt_wulfeck 10y ago
    Can you name a single trade where that's not also true? Keeping any mechanical thing running for years takes a lot of monkey-patching and duct tape. Technical debt in software engineering is not the exception. It's typical.
- jasonthevillain 10y ago
  > The engineer anxiety about them is myopic and ignorant of business realities. Far from. The worry is not "this code is old." Plenty of old code (especially boring old code) is cranking along just fine. The worry is that if an old, abstruse system stops working or has a critical security bug, there's a real risk that nobody will be able to put the fire out.
- khedoros1 10y ago
  > If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. Well, yeah, for the first version. But when is the first version also the last one? Not in many good situations. Crap that doesn't immediately collapse under its own weight will probably immediately collapse as soon as you add more weight to it in version 2. A lack of anxiety about the structure of the product is myopic and ignorant of engineering realities. There's got to be a balance. Too little anxiety, and you lose customers to competitors that spent more time to build a quality product, structured so that it's easier to grow. Too much anxiety, and you're in a "perfect is the enemy of good" situation, and you'll lose customers to competitors that were able to iterate faster and with a proper balance.

onion2k 10y ago

If I build a quick MVP, I can easily incrementally improve it. But you won't. Even if you want to, the client won't pay you to because all the client sees a working solution, so you never get the chance to. That's the problem the author is highlighting.

morgante 10y ago
Sure I will. Most products have continual work done on them. Code "quality" (whatever bullshit metric you use for that) is not the only metric of improvement. In fact, it's probably the least important metric to optimize over time.
- onion2k 10y ago
  Most products have continual work done on them. Usually that's new features and bug fixes. It's very rare to find a client who'll happily pay for refactoring. If you're in a job where you get time for that you should consider yourself very lucky indeed. EDIT: For what it's worth, I agree with your point about code quality. What's 'beautiful' now is only 'perfect' in the frame of the current feature set. It might be horrible if the next feature that comes along changes things dramatically. I'm very much of the opinion that "good is better than perfect", just with the addendum that the code at least has to be good. Bad code is just bad.

bsg75 10y ago

"Just ship it, we can iron out the bugs later" - later never comes because that cycle repeats ad nauseam.