5 ms·

Really? I think the best way to solve a problem is to code it. I can never see all the corner cases and logical inconsistencies before I start typing. I have tr

Really? I think the best way to solve a problem is to code it. I can never see all the corner cases and logical inconsistencies before I start typing. I have tried to formally model software before I start writing it and in the end it was largely a waste of time because real understanding of the problem comes with coding the solution. Of course when doing it like this you write a lot of code which later is unused or bad. But I think that will always happen and it's just a matter of having the discipline to continuously clean up after yourself.

braythwayt 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. 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.
  - 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?
mannykannot 7y ago
Really? yes, it is very common. The problem of this approach is that it does not scale to large systems. If you don't spend much time on thinking in the abstract about how it will work and what might go wrong, then, by the time you have written enough code to find that out, you may have gone a long way down the wrong path, and not all architectural-level mistakes and oversights can be patched over. No-one does this perfectly -- even people using formal methods will overlook things -- but, on a big project, if you don't put much effort into thinking ahead about how it should work, and try to identify the problems before you have coded them, you are likely to end up where, in fact, many projects do find themselves: with something that is nominally close to completion but very far from working. Those that are not canceled end up looking like legacy code even when brand new.
- deleted 7y ago
  [deleted]
- rowanG077 7y ago
  If you want to have low quality solutions that kinda work on the first try then sure go for it. Your approach will inevitably lead to insurmountable technical debt that can't be paid off. Big projects should be cut into smaller pieces where each piece can be relatively easily rewritten.
  - mannykannot 7y ago
    > Big projects should be cut into smaller pieces where each piece can be relatively easy rewritten. To come up with the right smaller pieces, you have to think about how they will work together to achieve the big picture. That means interfaces and their contracts, and if you get them wrong, you end up with pieces that don't fit together, and do not, collectively, get the job done. Big problems cannot be effectively solved in a bottom-up manner, and perhaps the most pervasive fallacy in software development today is the notion that the principle of modularity means you only have to think about code in small pieces.
    - rowanG077 7y ago
gaze 7y ago
I have found that the gap in understanding between thinking you understand something and implementing something as a program is often much smaller than the gap between having programmed something and having proven it.
- rowanG077 7y ago
  What do you mean having proven it? As in you tested it and it works or do you mean you have formally using math that your solutions always gives the correct result? If it's the former then this is part of building it. An implementation without proper testing is incomplete. If it's the later I actually agree. Only the most sensitive of applications require that level of sophistication though.
  - gaze 7y ago
    A mathematical proof or analytical solution. I understand that analytical solutions only apply for very narrow ranges of problems but... consider writing an analytical solution to a differential equation versus applying a numerical solver. A numerical solution rarely leads to as deep an understanding as an analytical solution or a number of approximations in various limits. I feel like we're in the limit of something analogous to writing numerical solvers and claiming understanding from observing the output.
ben509 7y ago
I often take the compromise technique: write a prototype and build off that. The prototype is generally a mess, but I throw that out anyway.

braythwayt 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. 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.
- 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?

mannykannot 7y ago

Really? yes, it is very common. The problem of this approach is that it does not scale to large systems. If you don't spend much time on thinking in the abstract about how it will work and what might go wrong, then, by the time you have written enough code to find that out, you may have gone a long way down the wrong path, and not all architectural-level mistakes and oversights can be patched over. No-one does this perfectly -- even people using formal methods will overlook things -- but, on a big project, if you don't put much effort into thinking ahead about how it should work, and try to identify the problems before you have coded them, you are likely to end up where, in fact, many projects do find themselves: with something that is nominally close to completion but very far from working. Those that are not canceled end up looking like legacy code even when brand new.

deleted 7y ago
[deleted]
rowanG077 7y ago
If you want to have low quality solutions that kinda work on the first try then sure go for it. Your approach will inevitably lead to insurmountable technical debt that can't be paid off. Big projects should be cut into smaller pieces where each piece can be relatively easily rewritten.
- mannykannot 7y ago
  > Big projects should be cut into smaller pieces where each piece can be relatively easy rewritten. To come up with the right smaller pieces, you have to think about how they will work together to achieve the big picture. That means interfaces and their contracts, and if you get them wrong, you end up with pieces that don't fit together, and do not, collectively, get the job done. Big problems cannot be effectively solved in a bottom-up manner, and perhaps the most pervasive fallacy in software development today is the notion that the principle of modularity means you only have to think about code in small pieces.
  - rowanG077 7y ago

gaze 7y ago

I have found that the gap in understanding between thinking you understand something and implementing something as a program is often much smaller than the gap between having programmed something and having proven it.

rowanG077 7y ago
What do you mean having proven it? As in you tested it and it works or do you mean you have formally using math that your solutions always gives the correct result? If it's the former then this is part of building it. An implementation without proper testing is incomplete. If it's the later I actually agree. Only the most sensitive of applications require that level of sophistication though.
- gaze 7y ago
  A mathematical proof or analytical solution. I understand that analytical solutions only apply for very narrow ranges of problems but... consider writing an analytical solution to a differential equation versus applying a numerical solver. A numerical solution rarely leads to as deep an understanding as an analytical solution or a number of approximations in various limits. I feel like we're in the limit of something analogous to writing numerical solvers and claiming understanding from observing the output.

ben509 7y ago

I often take the compromise technique: write a prototype and build off that. The prototype is generally a mess, but I throw that out anyway.