8 ms·

Writing a lot of code you later discard because it isn’t part of the final solution is like throwing clay on the table and then carving away the bits that don’t

Writing a lot of code you later discard because it isn’t part of the final solution is like throwing clay on the table and then carving away the bits that don’t fit. Nobody criticizes the sculptor for the clay that ends up on the floor, and clay is heavy. We carve away bits, they have no mass and don’t need to be swept up, all we have to do is cut them away, revealing the final program.

Gravityloss 7y ago
Planning for realistic levels of waste. Throwing away prototypes. Gradually making changes. Keeping backwards compatibility. Testing. Accommodating users with large collective investment in learning.
mannykannot 7y ago
This is not a useful analogy; it is more of an excuse for not trying to think things through. Would this be a reasonable analogy for building a bridge? If you don't have a reasonably detailed idea of what you want and how to achieve it, you are unlikely to get it. https://dilbert.com/strip/1991-9-6 https://dilbert.com/strip/1991-9-6
- rowanG077 7y ago
  Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and start over. I think code should be mostly the same.
  - 0x445442 7y ago
    I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. I'll also bet there's a whole host of software projects which use similar processes today. It's just that most of us writing DB skins for "The Enterprise" are rarely, if ever exposed to real engineering for the simple fact that quality software is expensive and typically, our organically grown solutions are good enough.
    - nwallin 7y ago
      > I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. Of course, but the Apollo 11 lunar lander was created without the aid of ubiquitous desktop computers. I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry. If Neo were to build a bridge in the Matrix, chances are his processes would bear little resemblance to those of the Army Corp of Engineers.
      - 0x445442 7y ago
        > I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry. For the guidance/control systems, I bet you're wrong.
  - mannykannot 7y ago
    Your designers are working with abstract models. They are thinking about problems at a conceptual model, they are not putting up structures and seeing if they work.
    - rowanG077 7y ago
      code is also an abstract model. The CAD designers absolutely test if things work. Why do you think almost every engineering bureau has 3D printers.
      - mannykannot 7y ago
        > Code is also an abstract model. Sure, but it is not the only one. You are allowed to think at other levels, and it can be quite useful, especially on larger systems.
  - ryandrake 7y ago
    Maybe if we treated the practice of software development more like bridge building, we would have better reliability, fewer outages, fewer zero-day exploits, fewer patches and bugfixes--software that actually works the first time, and every time for years.
    - Jtsummers 7y ago
      I work in aviation/defense. They try to treat it just like building bridges, and it's a disaster. Please don't. Software is a design practice/process. Not a building process. Any analogy should be to the design phase of other engineering disciplines.
- drdeca 7y ago
  In the analogy with the clay, I believe they are both adding and removing clay
- zbentley 7y ago
  > Would this be a reasonable analogy for building a bridge? That is also a useless analogy. Do bridge builders get to test and re-test their bridges in the real, non-simulated world? Can they instantly make a copy of their bridge with a few critical differences and see how the two behave? Can they re-build their bridge in minutes? Metaphors aside, I think history is ample evidence that "coding your way around a problem" rather than conceptualizing a solution first is a perfectly valid way to approach professional programming. It's not the only way, and it has drawbacks which others have pointed out here. So does the conceptualize-first approach: you might solve the wrong problem, make something inelastic in the face of changing requirements, or fall into the psychological trap of being attached to your mental model even when it turns out that you really didn't think of everything and have to make changes on the fly. I'm really tired of people being dogmatic about either approach ("move fast and break things/pivot; anyone else isn't really interested in getting stuff done!", "you're just a messy code monkey unless you can hold the solution in your head before you start!"). It's almost always veiled arrogance rather than honest improvement-seeking, in my experience.
  - mannykannot 7y ago
    Well, yes, it is a useless analogy... Oh, you meant to say that comparing bridge-building to software development would be a useless analogy? It's not an analogy I made - the point is that just because you can make a cute analogy, it doesn't mean it offers any insight. > I'm really tired of people being dogmatic about either approach Exactly - and the implication that I am being dogmatic is a straw man. I am simply opposed to arguments that depend on poor analogies. Furthermore, all of the bad things that you say can happen if you try to think ahead are as least as likely to happen if you don't, and especially if you have gone in the wrong direction for some time (I know the latter is a manifestation of the sunk-cost fallacy, but it happens a lot on real projects.)
- deleted 7y ago
  [deleted]
sidlls 7y ago
On the other hand the sculptor has considered the type of clay, the quantity, the tools she'd need to use to carve away those bits, and understands enough about what she wants to create to know what bits to carve away first. Programming may not be (all) math, but it's not art, either.
- hutzlibu 7y ago
  "Programming may not be (all) math, but it's not art, either." Huh? Maybe the kind of common 8-5 office programming around buisness logic is not, but to design any bigger project is definitely art.
- seanmcdirmid 7y ago
  Math can be considered an art, though not a fine art. Programming by either extension is an art (though again, not a fine art). https://en.m.wikipedia.org/wiki/Mathematics_and_art https://en.m.wikipedia.org/wiki/Mathematics_and_art
  - j88439h84 7y ago
    I don't see why it couldn't be a fine art.
    - seanmcdirmid 7y ago
      Perhaps it could be practiced as part of a fine art, but like carpentry, programming itself isn’t.
      - deleted 7y ago
        [deleted]
thaumasiotes 7y ago
> Writing a lot of code you later discard because it isn’t part of the final solution is like throwing clay on the table and then carving away the bits that don’t fit. How do you make a statue of an elephant?

Gravityloss 7y ago

Planning for realistic levels of waste. Throwing away prototypes. Gradually making changes. Keeping backwards compatibility. Testing. Accommodating users with large collective investment in learning.

mannykannot 7y ago

This is not a useful analogy; it is more of an excuse for not trying to think things through. Would this be a reasonable analogy for building a bridge? If you don't have a reasonably detailed idea of what you want and how to achieve it, you are unlikely to get it. https://dilbert.com/strip/1991-9-6 https://dilbert.com/strip/1991-9-6

rowanG077 7y ago
Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and start over. I think code should be mostly the same.
- 0x445442 7y ago
  I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. I'll also bet there's a whole host of software projects which use similar processes today. It's just that most of us writing DB skins for "The Enterprise" are rarely, if ever exposed to real engineering for the simple fact that quality software is expensive and typically, our organically grown solutions are good enough.
  - nwallin 7y ago
    > I'll bet the engineering process of the software written for the Apollo 11 lunar lander was much closer to the bridge building process than you might think. Of course, but the Apollo 11 lunar lander was created without the aid of ubiquitous desktop computers. I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry. If Neo were to build a bridge in the Matrix, chances are his processes would bear little resemblance to those of the Army Corp of Engineers.
    - 0x445442 7y ago
      > I imagine the SpaceX guidance/control software was written in a way that less resembles bridge-building/Apollo 11 lunar landers and more like the organic processes we see elsewhere in the software industry. For the guidance/control systems, I bet you're wrong.
- mannykannot 7y ago
  Your designers are working with abstract models. They are thinking about problems at a conceptual model, they are not putting up structures and seeing if they work.
  - rowanG077 7y ago
    code is also an abstract model. The CAD designers absolutely test if things work. Why do you think almost every engineering bureau has 3D printers.
    - mannykannot 7y ago
      > Code is also an abstract model. Sure, but it is not the only one. You are allowed to think at other levels, and it can be quite useful, especially on larger systems.
- ryandrake 7y ago
  Maybe if we treated the practice of software development more like bridge building, we would have better reliability, fewer outages, fewer zero-day exploits, fewer patches and bugfixes--software that actually works the first time, and every time for years.
  - Jtsummers 7y ago
    I work in aviation/defense. They try to treat it just like building bridges, and it's a disaster. Please don't. Software is a design practice/process. Not a building process. Any analogy should be to the design phase of other engineering disciplines.
drdeca 7y ago
In the analogy with the clay, I believe they are both adding and removing clay
zbentley 7y ago
> Would this be a reasonable analogy for building a bridge? That is also a useless analogy. Do bridge builders get to test and re-test their bridges in the real, non-simulated world? Can they instantly make a copy of their bridge with a few critical differences and see how the two behave? Can they re-build their bridge in minutes? Metaphors aside, I think history is ample evidence that "coding your way around a problem" rather than conceptualizing a solution first is a perfectly valid way to approach professional programming. It's not the only way, and it has drawbacks which others have pointed out here. So does the conceptualize-first approach: you might solve the wrong problem, make something inelastic in the face of changing requirements, or fall into the psychological trap of being attached to your mental model even when it turns out that you really didn't think of everything and have to make changes on the fly. I'm really tired of people being dogmatic about either approach ("move fast and break things/pivot; anyone else isn't really interested in getting stuff done!", "you're just a messy code monkey unless you can hold the solution in your head before you start!"). It's almost always veiled arrogance rather than honest improvement-seeking, in my experience.
- mannykannot 7y ago
  Well, yes, it is a useless analogy... Oh, you meant to say that comparing bridge-building to software development would be a useless analogy? It's not an analogy I made - the point is that just because you can make a cute analogy, it doesn't mean it offers any insight. > I'm really tired of people being dogmatic about either approach Exactly - and the implication that I am being dogmatic is a straw man. I am simply opposed to arguments that depend on poor analogies. Furthermore, all of the bad things that you say can happen if you try to think ahead are as least as likely to happen if you don't, and especially if you have gone in the wrong direction for some time (I know the latter is a manifestation of the sunk-cost fallacy, but it happens a lot on real projects.)
deleted 7y ago
[deleted]

sidlls 7y ago

On the other hand the sculptor has considered the type of clay, the quantity, the tools she'd need to use to carve away those bits, and understands enough about what she wants to create to know what bits to carve away first. Programming may not be (all) math, but it's not art, either.

hutzlibu 7y ago
"Programming may not be (all) math, but it's not art, either." Huh? Maybe the kind of common 8-5 office programming around buisness logic is not, but to design any bigger project is definitely art.
seanmcdirmid 7y ago
Math can be considered an art, though not a fine art. Programming by either extension is an art (though again, not a fine art). https://en.m.wikipedia.org/wiki/Mathematics_and_art https://en.m.wikipedia.org/wiki/Mathematics_and_art
- j88439h84 7y ago
  I don't see why it couldn't be a fine art.
  - seanmcdirmid 7y ago
    Perhaps it could be practiced as part of a fine art, but like carpentry, programming itself isn’t.
    - deleted 7y ago
      [deleted]

thaumasiotes 7y ago

> Writing a lot of code you later discard because it isn’t part of the final solution is like throwing clay on the table and then carving away the bits that don’t fit. How do you make a statue of an elephant?