12 ms·

Who builds a house without drawing blueprints? (2015)

19 points by mxschumacher 6y ago

pintxo 6y ago
My TLDR: > 1h of up-front thinking about the problem and your solution can save you days of refactoring, testing, debugging. The author proposes writing specifications as good way of up-front thinking. Authors own conclusion: > There is nothing magical about specification. It will not eliminate all errors. It cannot catch coding errors; you will still have to test and debug to find them. (Language design and debugging tools have made great progress in catching coding errors, but they are not good for catching design errors.) And even a formal specification that has been proved to satisfy its required properties could be wrong if the requirements are incorrect. Thinking does not guarantee that you will not make mistakes. But not thinking guarantees that you will.
- aesyondu 6y ago
  We can shorten it further. Dwight D. Eisenhower once said, "In preparing for battle I have always found that plans are useless but planning is indispensable."
- teekert 6y ago
  Pro-tip: Do this with others. I have some colleagues that without fail are better then me at structuring my own thoughts and before writing a large amount of code I almost always explain my goals to them.
doctor_eval 6y ago
I don’t actually disagree with anything in the article, but comparisons between software and buildings - especially buildings - leave me cold. There is almost nothing actually in common between software and buildings. You can’t move a house as a matter of course. You can’t modify a house in a few keystrokes. You can’t just copy a house or delete it. You don’t generally consider how a house will evolve over time. A house has a limited number of possible states, and a trivially low number of entrances and exits. The analogy is so poor that it’s difficult even to make analogies about how bad an analogy it is. I have thought for a long time that building analogies are horribly ill suited to software. Perhaps better than nothing, but only barely. Software is a thing unto itself and I just find these analogies make we want to run away screaming.
- paulmooreparks 6y ago
  As the article states, "However, metaphors can be misleading, and I do not claim that we should write specifications just because architects draw blueprints." He's not arguing for specifications because architects draw them for builders. Rather, architects draw them for some of the same reasons that the author posits that software specifications should be written. As it says elsewhere... "[A]s the cartoonist Guindon wrote: 'Writing is nature's way of letting you know how sloppy your thinking is.' We think in order to understand what we are doing. If we understand something, we can explain it clearly in writing. If we have not explained it in writing, then we do not know if we really understand it." That's why one should write specifications.
  - TheOtherHobbes 6y ago
    A written software specification can still be spectacularly wrong. Writing down a spec is no guarantee that you have avoided fuzzy and incomplete thinking or that you understand the problem you are trying to solve.
    - paulmooreparks 6y ago
      Also covered in the article.
  - doctor_eval 6y ago
    Like I say, I don’t disagree with anything in the article. In fact I’d go further and say that the metaphor is not just misleading, but actually damaging.
- WJW 6y ago
  I wonder how architects would go about their jobs differently if they could build a new house in a few seconds, run a few thousand unit tests on it and then tear it down again at almost zero cost.
  - goalieca 6y ago
    They can in modelling tools.
yonixw 6y ago
Just like with real estate agents, most times they oversell and charge more just because some new paint. Same with software, dozen of times I planned out a solution just to find that a component does not support a case or have a bug. Thankfully we can just "Fail Fast" in software. So we should use it.
eitland 6y ago
> Architects draw detailed plans before a brick is laid or a nail is hammered. But few programmers write even a rough sketch of what their programs will do before they start coding. Is the second sentence here true in any meaningful way? Usually when I start on a personal project that is bigger than a oneliner or a script and more novel than a web page I've been thinking about it for weeks and have made a few sketches of the architecture and key data models and even then I start with a rough outline of the code ready to throw it away. I don't think everyone does like me but it would surprise me if most professional programmers doesn't make some kind of sketch before starting on a project..? Either I'm really unusually professional (I don't think so) or this article has a weak starting point.
StavrosK 6y ago
I liked the article and tried to look into TLA+, but the documentation is off-putting at every turn. There is no HTML documentation, you need to download a ZIP of a book. Opening the ZIP, it's not just a single PDF, it's a bunch of PDFs (many a page or paragraph long) that the table of contents hyperlinks to. This makes impossible to skim the documentation. Looking at some examples, it looks like TLA+ uses non-ASCII symbols which are then maybe mapped to ASCII? As such, you need to remember lots of obscure sigils, and I couldn't find a high-level intro of how it works. It sounds very interesting, but the documentation could be made much more helpful. Lamport comments that "people nowadays don't read, so I made a video course", but I'm not surprised people don't read if reading is this hard. (I personally dislike video courses because you can't skim them and would much prefer HTML documentation).
- grndn 6y ago
  Agreed about the TLA docs, but it is worth persisting, as TLA is very useful in some situations. These slides cover the basic syntax enough to get started. https://www.slideshare.net/ScottWlaschin/tla-for-programmers-235339832 https://www.slideshare.net/ScottWlaschin/tla-for-programmers...
  - StavrosK 6y ago
    Thank you, that's very useful.
- hwayne 6y ago
  I wrote an online guide designed to be a bit more accessible: https://www.learntla.com https://www.learntla.com (I stopped working on it to write a full book, but now that that's done I really need to get back and overhaul it. Still a useful resource IMO)
  - StavrosK 6y ago
    This is really well done, thank you. It's so well done that I'm reading just because it's so interesting, I was afraid my eyes would glaze over but I'm really engrossed by how you're qualifying the problem first.
deleted 6y ago
[deleted]
Pinus 6y ago
When building a house, there is a considerable difference in effort between making detailed construction drawing and building the house, so it makes sense to make a detailed construction drawing. In software, there is effectively no difference between making a detailed design and actually writing the program, so it becomes a lot harder to know where to stop drawing and start building. I guess that many of us have, at some point, thought we had come up with a good design, after spending lots of time on it, only to find that it stumbled on some detail when we actually tried to implement it. This makes it tempting to think "If I must work this out in detail anyway, I might as well do it in code. That way, if I get it right the first time around, I will be done!" Unfortunately, it also makes it tempting to stick with a design after it has proven to be a mistake, because of the sunk cost. (edit: grammar.)
deleted 6y ago
[deleted]
Gravityloss 6y ago
It does feel that a lot of buildings were designed with very little effort and are just a random arrangements of components and some patch work to make it passable. There are so many weird solutions, especially in newer buildings. Far too few entrances and exits. Doors opening the wrong way, or extra doors or short stairs you have to pass through. Random looking window sizes and placements. Or no windows. Or no windows to the side with the best views, instead all facing a close by building. Having to walk around a lot for basic oft repeating functions - ie stairs or elevators that feel like they are installed backwards. I did some hobbbyist 3d shooter level design in the past, and played a lot of custom maps. You could see the high level "flow" and vision of master designers when playing their maps or looking at them in the editor. Less experienced mappers might have some good individual ideas but the whole would usually not be so coherent.
imtringued 6y ago
The building analogy doesn't work because the situation is completely reversed. Building commercial software is much cheaper than designing it. Constructing a building is much more expensive than designing it. Specifications are expensive and since designing software is risky the specification forces you to take the entire risk upfront. Lots of projects stop after a failed MVP to cut losses. You can't do that with a well thought out specification. There are obviously well studied areas of computer science where the opposite is true. Compilers, databases and simulations benefit from a good design but this is precisely because of their well studied nature. The only way to get an edge in the commercial world is by doing something nobody else did before. That often means nobody, including the creator of the software, knows what the best design is. This commonly results in an "idiotic market leader" effect where a product with obvious flaws (say mongodb) somehow manages to dominate a market.
dang 6y ago
Discussed at the time: https://news.ycombinator.com/item?id=9287426 https://news.ycombinator.com/item?id=9287426

19 points by mxschumacher 6y ago

My TLDR: > 1h of up-front thinking about the problem and your solution can save you days of refactoring, testing, debugging. The author proposes writing specifications as good way of up-front thinking. Authors own conclusion: > There is nothing magical about specification. It will not eliminate all errors. It cannot catch coding errors; you will still have to test and debug to find them. (Language design and debugging tools have made great progress in catching coding errors, but they are not good for catching design errors.) And even a formal specification that has been proved to satisfy its required properties could be wrong if the requirements are incorrect. Thinking does not guarantee that you will not make mistakes. But not thinking guarantees that you will.

aesyondu 6y ago
We can shorten it further. Dwight D. Eisenhower once said, "In preparing for battle I have always found that plans are useless but planning is indispensable."
teekert 6y ago
Pro-tip: Do this with others. I have some colleagues that without fail are better then me at structuring my own thoughts and before writing a large amount of code I almost always explain my goals to them.

doctor_eval 6y ago

I don’t actually disagree with anything in the article, but comparisons between software and buildings - especially buildings - leave me cold. There is almost nothing actually in common between software and buildings. You can’t move a house as a matter of course. You can’t modify a house in a few keystrokes. You can’t just copy a house or delete it. You don’t generally consider how a house will evolve over time. A house has a limited number of possible states, and a trivially low number of entrances and exits. The analogy is so poor that it’s difficult even to make analogies about how bad an analogy it is. I have thought for a long time that building analogies are horribly ill suited to software. Perhaps better than nothing, but only barely. Software is a thing unto itself and I just find these analogies make we want to run away screaming.

paulmooreparks 6y ago
As the article states, "However, metaphors can be misleading, and I do not claim that we should write specifications just because architects draw blueprints." He's not arguing for specifications because architects draw them for builders. Rather, architects draw them for some of the same reasons that the author posits that software specifications should be written. As it says elsewhere... "[A]s the cartoonist Guindon wrote: 'Writing is nature's way of letting you know how sloppy your thinking is.' We think in order to understand what we are doing. If we understand something, we can explain it clearly in writing. If we have not explained it in writing, then we do not know if we really understand it." That's why one should write specifications.
- TheOtherHobbes 6y ago
  A written software specification can still be spectacularly wrong. Writing down a spec is no guarantee that you have avoided fuzzy and incomplete thinking or that you understand the problem you are trying to solve.
  - paulmooreparks 6y ago
    Also covered in the article.
- doctor_eval 6y ago
  Like I say, I don’t disagree with anything in the article. In fact I’d go further and say that the metaphor is not just misleading, but actually damaging.
WJW 6y ago
I wonder how architects would go about their jobs differently if they could build a new house in a few seconds, run a few thousand unit tests on it and then tear it down again at almost zero cost.
- goalieca 6y ago
  They can in modelling tools.

yonixw 6y ago

Just like with real estate agents, most times they oversell and charge more just because some new paint. Same with software, dozen of times I planned out a solution just to find that a component does not support a case or have a bug. Thankfully we can just "Fail Fast" in software. So we should use it.

eitland 6y ago

> Architects draw detailed plans before a brick is laid or a nail is hammered. But few programmers write even a rough sketch of what their programs will do before they start coding. Is the second sentence here true in any meaningful way? Usually when I start on a personal project that is bigger than a oneliner or a script and more novel than a web page I've been thinking about it for weeks and have made a few sketches of the architecture and key data models and even then I start with a rough outline of the code ready to throw it away. I don't think everyone does like me but it would surprise me if most professional programmers doesn't make some kind of sketch before starting on a project..? Either I'm really unusually professional (I don't think so) or this article has a weak starting point.

StavrosK 6y ago

I liked the article and tried to look into TLA+, but the documentation is off-putting at every turn. There is no HTML documentation, you need to download a ZIP of a book. Opening the ZIP, it's not just a single PDF, it's a bunch of PDFs (many a page or paragraph long) that the table of contents hyperlinks to. This makes impossible to skim the documentation. Looking at some examples, it looks like TLA+ uses non-ASCII symbols which are then maybe mapped to ASCII? As such, you need to remember lots of obscure sigils, and I couldn't find a high-level intro of how it works. It sounds very interesting, but the documentation could be made much more helpful. Lamport comments that "people nowadays don't read, so I made a video course", but I'm not surprised people don't read if reading is this hard. (I personally dislike video courses because you can't skim them and would much prefer HTML documentation).

grndn 6y ago
Agreed about the TLA docs, but it is worth persisting, as TLA is very useful in some situations. These slides cover the basic syntax enough to get started. https://www.slideshare.net/ScottWlaschin/tla-for-programmers-235339832 https://www.slideshare.net/ScottWlaschin/tla-for-programmers...
- StavrosK 6y ago
  Thank you, that's very useful.
hwayne 6y ago
I wrote an online guide designed to be a bit more accessible: https://www.learntla.com https://www.learntla.com (I stopped working on it to write a full book, but now that that's done I really need to get back and overhaul it. Still a useful resource IMO)
- StavrosK 6y ago
  This is really well done, thank you. It's so well done that I'm reading just because it's so interesting, I was afraid my eyes would glaze over but I'm really engrossed by how you're qualifying the problem first.

deleted 6y ago

[deleted]

Pinus 6y ago

When building a house, there is a considerable difference in effort between making detailed construction drawing and building the house, so it makes sense to make a detailed construction drawing. In software, there is effectively no difference between making a detailed design and actually writing the program, so it becomes a lot harder to know where to stop drawing and start building. I guess that many of us have, at some point, thought we had come up with a good design, after spending lots of time on it, only to find that it stumbled on some detail when we actually tried to implement it. This makes it tempting to think "If I must work this out in detail anyway, I might as well do it in code. That way, if I get it right the first time around, I will be done!" Unfortunately, it also makes it tempting to stick with a design after it has proven to be a mistake, because of the sunk cost. (edit: grammar.)

deleted 6y ago

[deleted]

Gravityloss 6y ago

It does feel that a lot of buildings were designed with very little effort and are just a random arrangements of components and some patch work to make it passable. There are so many weird solutions, especially in newer buildings. Far too few entrances and exits. Doors opening the wrong way, or extra doors or short stairs you have to pass through. Random looking window sizes and placements. Or no windows. Or no windows to the side with the best views, instead all facing a close by building. Having to walk around a lot for basic oft repeating functions - ie stairs or elevators that feel like they are installed backwards. I did some hobbbyist 3d shooter level design in the past, and played a lot of custom maps. You could see the high level "flow" and vision of master designers when playing their maps or looking at them in the editor. Less experienced mappers might have some good individual ideas but the whole would usually not be so coherent.

imtringued 6y ago

The building analogy doesn't work because the situation is completely reversed. Building commercial software is much cheaper than designing it. Constructing a building is much more expensive than designing it. Specifications are expensive and since designing software is risky the specification forces you to take the entire risk upfront. Lots of projects stop after a failed MVP to cut losses. You can't do that with a well thought out specification. There are obviously well studied areas of computer science where the opposite is true. Compilers, databases and simulations benefit from a good design but this is precisely because of their well studied nature. The only way to get an edge in the commercial world is by doing something nobody else did before. That often means nobody, including the creator of the software, knows what the best design is. This commonly results in an "idiotic market leader" effect where a product with obvious flaws (say mongodb) somehow manages to dominate a market.

dang 6y ago

Discussed at the time: https://news.ycombinator.com/item?id=9287426 https://news.ycombinator.com/item?id=9287426