6 ms·

I don’t actually disagree with anything in the article, but comparisons between software and buildings - especially buildings - leave me cold. There is almost

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.
  - WJW 6y ago
    Do they actually run unit tests over those? I've seen the VR modelers where you can "walk" through the builidng but those didn't really verify whether there was enough room in the walls for piping, light fall, floor strength limits, fire requirements etc. I know at least one department in the Dutch navy was using constraint solvers to design a new submarine class but I haven't heard about a lot about house design. Not a home architect though, so maybe I just haven't kept up to the state of the art there.
    - tonyarkles 6y ago
      > do they run unit tests on those My initial glib answer is “no, the engineers are stuck to deal with the bad design afterwards” :) My less glib answer would be that most disciplines of engineering do do modelling and “virtual testing”. I’ve been working on largish drones for about 18 months. Electronics get specced out, circuits get drawn and simulated, currents are estimated and components are specced based on those estimates, etc. On the mechanical side, parts are drawn in CAD, analyzed for proper fit and assemble-ability, FEA is used to determine whether a part is likely to be strong enough for the static and dynamic loads that will be placed on the aircraft, etc. All of this happens, generally, before circuit boards or modules get ordered or before the first chunk of aluminum goes into the CNC. As far as building software goes, I’ve recently had to start digging into DO-178C, and I’m pretty impressed so far. Despite having been through engineering school (EE), I haven’t ever really had to put this level of rigour into practice for software before. It feels slow and somewhat time consuming, but I’m feeling more and more confident that the module I’m working on is going to be pretty damned robust. It’s not a “certification required” unit, but it would be a huge pain in the ass if it failed and couldn’t recover without human intervention; as a result I’m doing more of a “DO-178C lite” with detailed low-level requirements stated explicitly, system architecture drawn out first, sequence diagrams for the complicated event-driven parts, state charts for the different parallel systems, etc.
forgotmypw17 6y ago
I think a blueprint is more like the source code, and a building is more like an instance of the software running in memory.
- adrianN 6y ago
  Even that comparison is bad, because a large part of the problems you might have with a house are not because of a bad blue print, but because it wasn't built properly.
  - Retric 6y ago
    Bad construction errors are almost entirely an issue of bad design. The more complex the roof line, the more likely you are to have leaks. Using multiple types of cladding is similarly inviting a host of issues. etc etc There is still plenty of room to mess up the details, but that tends to be easier to ignore and cheaper to fix.
lucideer 6y ago
I agree that analogies and metaphors are always inaccurate and always misleading. And often pointless. But: > You don’t generally consider how a house will evolve over time. A house has a limited number of possible states I don't believe either of these are true > and a trivially low number of entrances and exits. and I believe good software should strive to have a similarly low number Obviously I'm nitpicking, but I don't believe buildings are necessarily worse than other terrible software analogies.
- doctor_eval 6y ago
  My point is really that we don’t use analogies to design houses and I think we should stop using analogies to design software. To your first point, I’ve built a couple of houses, and I’ve never had to worry about how they would evolve or be modified by others after they were built.
  - lucideer 6y ago
    As someone who's known a fair few architects, we unfortunately do use analogies to design houses. Sadly. Glad to hear you don't when designing yours though. > I’ve never had to worry about how they would evolve or be modified by others after they were built. That seems unfortunate. Isn't that something you should want to consider (though you describe it as an undesirable, which seems a shortsighted view of the purpose of buildings).
    - imtringued 6y ago
      How would you remove the third floor of a 5 story building? I'm sure its possible.
      - lucideer 6y ago
        It's probably possible, but I'd say it might be slightly easier to remove the 5th floor. After which the 3rd & 4th could be.. you know.. evolved. I've also more often seen space in buildings moved horizontally rather than vertically.
cam_l 6y ago
Your phrasing suggests a comparison between 1. a finished building and 2. the process of making a piece of software.. of course there is no comparison. If you look at a more apples to apples comparison, ie. designing (and in that I would include designing the process of building) a bespoke building. Designing a building is about structuring a building process, a business process, a living process, a manufacturing process, or public interface, a place of work, or life, or learning or wonder, all within or about the confines of a building. Even simple bespoke buildings bring together hundreds of thousands or even millions of parts which have never been put together in this way or by these particular people before. You have to consider how all these materials fit together, behave together, how they degrade over time, their warranties, their performance, how they will get removed, replaced, disposed of. You have to consider how buildings will be modified, or inhabited or changed over time (because if you can't change it, it will be knocked down). You have to account for the wildly differing preferences for taste, or comfort, or usage of buildings which your clients cannot describe and often have no awareness of. Your client is sometimes the end user, but most end users are not clients. You have no control over any of the important decision making processes, but lots of control over the unimportant ones. All of your attempts to standardise the process in order to contain timeframes result in an incremental lessening of quality or usefulness - sometimes to the effect that the finished product horribly underserves the end users (you often make the clients happy though). Clients also sometimes just refuse to pay. Architects have been thinking about and writing about and experimenting with information gathering, processing and dissemination for (at least) hundreds of years. I mean, architects were knowledge workers before we even had paper to draw the blueprints on. Much of the early systems of standardisation and automation were driven by architecture (and fashion surely). Hell, the first 3D scanning of an object, a statue, was in the 15thC by an architect.[0] We have been using ticket systems ( rfis), bug reports (post occupation evaluation) and version control systems (transmittals and revisions) for longer than the software industry has been around. The reason for all the arcane processes in the industry is to try to capture, use and re-use information. To standardise processes across consultants, builders, clients, and manufacturers. Most architects are shit, we developed horrible hiring procedures to weed out the shit ones, that don't really work. They chronically underpay staff. They have missed just as many deadlines, and spent just as much money in cost blowouts as the software industry. No. Designing buildings is almost exactly like designing software. It is just data processing and prediction after all.. and bullshit. Everything new is old. You can probably learn from their mistakes. [0] https://www.smithsonianmag.com/arts-culture/digital-files-and-3d-printingin-the-renaissance-244207/ https://www.smithsonianmag.com/arts-culture/digital-files-an...
jp57 6y ago
Yes, building analogies are terrible for coding. A much better analogy is writing. Writing code a lot like writing. You do it by typing documents in an editor. You revise them. You might have a written outline first, just an outline in your head, or none at all. Revision is important. Before you publish, it is very helpful to have a few smart people you trust read your work over and tell you what's wrong with it, etc.
- deleted 6y ago
  [deleted]
hwayne 6y ago
I've interviewed a bunch of people who used to professionally design buildings and now professionally write software. They have a lot more in common than you think.
- mbrodersen 6y ago
  That's interesting. Can you elaborate on where the similarities are? Thanks

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.
- WJW 6y ago
  Do they actually run unit tests over those? I've seen the VR modelers where you can "walk" through the builidng but those didn't really verify whether there was enough room in the walls for piping, light fall, floor strength limits, fire requirements etc. I know at least one department in the Dutch navy was using constraint solvers to design a new submarine class but I haven't heard about a lot about house design. Not a home architect though, so maybe I just haven't kept up to the state of the art there.
  - tonyarkles 6y ago
    > do they run unit tests on those My initial glib answer is “no, the engineers are stuck to deal with the bad design afterwards” :) My less glib answer would be that most disciplines of engineering do do modelling and “virtual testing”. I’ve been working on largish drones for about 18 months. Electronics get specced out, circuits get drawn and simulated, currents are estimated and components are specced based on those estimates, etc. On the mechanical side, parts are drawn in CAD, analyzed for proper fit and assemble-ability, FEA is used to determine whether a part is likely to be strong enough for the static and dynamic loads that will be placed on the aircraft, etc. All of this happens, generally, before circuit boards or modules get ordered or before the first chunk of aluminum goes into the CNC. As far as building software goes, I’ve recently had to start digging into DO-178C, and I’m pretty impressed so far. Despite having been through engineering school (EE), I haven’t ever really had to put this level of rigour into practice for software before. It feels slow and somewhat time consuming, but I’m feeling more and more confident that the module I’m working on is going to be pretty damned robust. It’s not a “certification required” unit, but it would be a huge pain in the ass if it failed and couldn’t recover without human intervention; as a result I’m doing more of a “DO-178C lite” with detailed low-level requirements stated explicitly, system architecture drawn out first, sequence diagrams for the complicated event-driven parts, state charts for the different parallel systems, etc.

forgotmypw17 6y ago

I think a blueprint is more like the source code, and a building is more like an instance of the software running in memory.

adrianN 6y ago
Even that comparison is bad, because a large part of the problems you might have with a house are not because of a bad blue print, but because it wasn't built properly.
- Retric 6y ago
  Bad construction errors are almost entirely an issue of bad design. The more complex the roof line, the more likely you are to have leaks. Using multiple types of cladding is similarly inviting a host of issues. etc etc There is still plenty of room to mess up the details, but that tends to be easier to ignore and cheaper to fix.

lucideer 6y ago

I agree that analogies and metaphors are always inaccurate and always misleading. And often pointless. But: > You don’t generally consider how a house will evolve over time. A house has a limited number of possible states I don't believe either of these are true > and a trivially low number of entrances and exits. and I believe good software should strive to have a similarly low number Obviously I'm nitpicking, but I don't believe buildings are necessarily worse than other terrible software analogies.

doctor_eval 6y ago
My point is really that we don’t use analogies to design houses and I think we should stop using analogies to design software. To your first point, I’ve built a couple of houses, and I’ve never had to worry about how they would evolve or be modified by others after they were built.
- lucideer 6y ago
  As someone who's known a fair few architects, we unfortunately do use analogies to design houses. Sadly. Glad to hear you don't when designing yours though. > I’ve never had to worry about how they would evolve or be modified by others after they were built. That seems unfortunate. Isn't that something you should want to consider (though you describe it as an undesirable, which seems a shortsighted view of the purpose of buildings).
  - imtringued 6y ago
    How would you remove the third floor of a 5 story building? I'm sure its possible.
    - lucideer 6y ago
      It's probably possible, but I'd say it might be slightly easier to remove the 5th floor. After which the 3rd & 4th could be.. you know.. evolved. I've also more often seen space in buildings moved horizontally rather than vertically.

cam_l 6y ago

Your phrasing suggests a comparison between 1. a finished building and 2. the process of making a piece of software.. of course there is no comparison. If you look at a more apples to apples comparison, ie. designing (and in that I would include designing the process of building) a bespoke building. Designing a building is about structuring a building process, a business process, a living process, a manufacturing process, or public interface, a place of work, or life, or learning or wonder, all within or about the confines of a building. Even simple bespoke buildings bring together hundreds of thousands or even millions of parts which have never been put together in this way or by these particular people before. You have to consider how all these materials fit together, behave together, how they degrade over time, their warranties, their performance, how they will get removed, replaced, disposed of. You have to consider how buildings will be modified, or inhabited or changed over time (because if you can't change it, it will be knocked down). You have to account for the wildly differing preferences for taste, or comfort, or usage of buildings which your clients cannot describe and often have no awareness of. Your client is sometimes the end user, but most end users are not clients. You have no control over any of the important decision making processes, but lots of control over the unimportant ones. All of your attempts to standardise the process in order to contain timeframes result in an incremental lessening of quality or usefulness - sometimes to the effect that the finished product horribly underserves the end users (you often make the clients happy though). Clients also sometimes just refuse to pay. Architects have been thinking about and writing about and experimenting with information gathering, processing and dissemination for (at least) hundreds of years. I mean, architects were knowledge workers before we even had paper to draw the blueprints on. Much of the early systems of standardisation and automation were driven by architecture (and fashion surely). Hell, the first 3D scanning of an object, a statue, was in the 15thC by an architect.[0] We have been using ticket systems ( rfis), bug reports (post occupation evaluation) and version control systems (transmittals and revisions) for longer than the software industry has been around. The reason for all the arcane processes in the industry is to try to capture, use and re-use information. To standardise processes across consultants, builders, clients, and manufacturers. Most architects are shit, we developed horrible hiring procedures to weed out the shit ones, that don't really work. They chronically underpay staff. They have missed just as many deadlines, and spent just as much money in cost blowouts as the software industry. No. Designing buildings is almost exactly like designing software. It is just data processing and prediction after all.. and bullshit. Everything new is old. You can probably learn from their mistakes. [0] https://www.smithsonianmag.com/arts-culture/digital-files-and-3d-printingin-the-renaissance-244207/ https://www.smithsonianmag.com/arts-culture/digital-files-an...

jp57 6y ago

Yes, building analogies are terrible for coding. A much better analogy is writing. Writing code a lot like writing. You do it by typing documents in an editor. You revise them. You might have a written outline first, just an outline in your head, or none at all. Revision is important. Before you publish, it is very helpful to have a few smart people you trust read your work over and tell you what's wrong with it, etc.

deleted 6y ago
[deleted]

hwayne 6y ago

I've interviewed a bunch of people who used to professionally design buildings and now professionally write software. They have a lot more in common than you think.

mbrodersen 6y ago
That's interesting. Can you elaborate on where the similarities are? Thanks