5 ms·

The author makes some great points that I initially wanted to dismiss, but I think are actually really interesting. Unlike many other types of engineering/craft

• morgante 10y ago
  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.
• jghn 10y ago
  Where your analogy starts to break down is that it is increasingly hard to find those top quality craftsfolk as many people aren't willing to pay the prices they command and instead go to cheaper labor who don't do as great of a job.
• woah 10y ago
  I'll have to disagree. I used to be a carpenter and the objective is definitely not to be perfect. Building anything, houses or apps, the objective is to work within tolerances. The modern system of 2x4 framing and drywall allows those tolerances to be very loose without affecting the end product, but I digress. Would you prefer a half-finished house with perfectly cut studs (that you can't see inside the drywall), or a completed house that has looser tolerances but has passed inspection? Even in those fields that people imagine involve a lot of perfection, like watercolors or fine Japanese carpentry, the perfection is not arrived at by agonizing over details and overworking the piece. The perfection comes from the muscle memory of someone who has done it many times. App development should be the same way. This economy of effort is intrinsic to any craft and is part of being a good craftsperson. I used to have an attitude similar to the author, a mixture of derision and envy towards those who were able to ship. She needs to learn that if she does not abandon this counterproductive mental handicap, she will never be a good craftsperson, in software or anything else.
  • carsie 10y ago
    Thank you for sharing your thoughts here, this is so well put and I completely second this. I find the beauty of code is not in adhering to someones concept of elegantly written code, that only the coders see, but in the fact that it's living, and that over time your solution can evolve to become better than its intended purpose. Something observed to be perfect usually has a past that is often overlooked.
  • rm999 10y ago
    There's a huge difference in economics. A house will be used, so looser tolerances in carpentry are not obviously good and are seen by many as a bad trend. Sure, you may not die from those lower tolerances, but you'll likely regret it. See for example http://www.mcmansionhell.com/post/150597521816/mcmansions-101-revisited-aesthetics-aside-why http://www.mcmansionhell.com/post/150597521816/mcmansions-10... The median house will be used for decades, the median software is used for months (maybe days, or even minutes). This is really what my point is.
    • barrkel 10y ago
• user5994461 10y ago
  I'd rather give a completely different explanation. Building 90% of a software is easy, getting to 100% is insanely difficult. Building 90% of a construction/hardware/car/... is hard, the final bits are easy.
  • slowmovintarget 10y ago
    No, the last 10% of completing the house, car, machine, or meal preparation is still the most difficult, just like in software. Finishing always requires more attention to detail, and a tougher sense of good-enough than the first 90%.
• DannyBee 10y ago
  " A good carpenter wants to build a solid house even if no one will ever see its frame. Ditto to an auto engineer at BMW, or a hardware engineer at Apple, or a mechanical engineer at Boeing. Why do software engineers break this mold? " They don't, but a good carpenter is not going to try to figure out how to make every single wall perfectly 90 degrees, etc. He's going to take a level, see if the thing is in a center for a given stud, make that work, and then move on. They never perfect the end result. None of the walls in your house are likely perfectly square and plumb They also use imperfect building materials, and so they know that a year from now, even if it was square, it wouldn't be anymore. Carpenters, more than anyone, are true believers in "good enough". I'd argue most of your other examples are the same. That said, the problem she complains about is real. She is, in essence, a programmer from 30-40 years ago. When you had to share time on computers, and your software broke, you didn't just poke it repeatedly until it worked, because you couldn't. Instead, you sat on a mountain and meditated upon your code, until you understood it well enough to fix the problem and try again. In that sense, the thing that has really changed is not the cost, it's the speed at which you can throw shit at the wall. Development is so fast nowadays that programmers don't stop to think about the real underlying problem, they just want to make the compiler shut up or the program keep going. They just want to solve whatever their immediate problem is. The cost incentive was always there. People always wanted good software as fast as it could be built. It was the speed of being able to build it that made people concerned with quality. Now that they can essentially build it at light speed, nobody cares, because it's only how it seems to work that matters. IE doing things the wrong way to achieve the result people want is fine, even if it causes longer term problems. You can see this in pretty much any long-running (IE 15+ year) open source project.
  • rokhayakebe 10y ago
    Instead, you sat on a mountain and meditated upon your code, until you understood it well enough to fix the problem and try again. :)
    • user5994461 10y ago
      And it was the most productive time of your life. Never, at any point in your meditation or mountain ascension, did you introduce a single bug or provoked any issue to any user =)
• kabes 10y ago
  I think it's mainly because software engineering is still more an art than a science. Although we may have formal engineering education, most of us end up making business logic where there are few rules on how to do it. You can't compare it with building a bridge, which has a strict mathematical workflow.
  • thwarted 10y ago
    I think it's mainly because software engineering is still more an art than a science. The use of the word "still" here implies that it will be, or that it should be, more "science" than "art". As an act of creation and navigating ever changing constraints, I think it is more art, and will have art be a major component of it for a long time, if not forever.
• enraged_camel 10y ago
  I would posit that's the main difference between a craftsman and an engineer. A craftsman pours his heart and soul into his work and aims for perfection. An engineer, on the other hand, has to work within certain constraints, such as time and budget. Of course, the definition of "perfect" is different for everyone. The point is that craftsmen can wait until they're fully satisfied with what they are working on before releasing it. Engineers don't have that luxury.
• Eridrus 10y ago
  The lament that software engineering is not real engineering because we eschew formal methods is one I've heard a lot (not from you), but in those fields testing and failure are very, very expensive. In places where failures are expensive, such as high volume websites, we use techniques such as A/B testing to limit the scope of expense of failures and detect them earlier. In cases where failure is truly unacceptable we take more drastic measures such as formal verification, restricting programmer freedom through coding standards, etc. Even he dramatic story about having a wrong number read out on NPR you'll notice she is the one punishing herself; no-one really admonishes her, there are no negative repercussions. As economic pressures have increased in journalism, this attitude that everything must be fact checked has fallen by the wayside since it is not economically viable any more. This economic pressure coincides with mass adoption of the internet though, and the real cause may not just be their declining ad revenue, but the increased competition between news outlets to be first, since that's what drives clicks. The saying that the perfect is the enemy of the good exists for a reason.