10 ms·

Who Builds a House Without Drawing Blueprints?

• herpelderp 12y ago
  Bees
  • lukesan 12y ago
    Yes, in an iterative way. Maybe it is also agile :)
    • Ygg2 12y ago
      Agile Swarm Manifesto?
  • justincormack 12y ago
    And the Winchester Mystery House [1] [1] https://en.wikipedia.org/wiki/Winchester_Mystery_House https://en.wikipedia.org/wiki/Winchester_Mystery_House
  • erikb 12y ago
    While you might have a good point it's hard to see for me, because I fail to have your context. Please provide.
• MBlume 12y ago
  I know the author's entire argument doesn't stand or fall with the simile, but it still needs to be said: blueprints are more necessary for physical construction than they are for software because things made of wood and concrete are hard to change part-way through.
  • pjbrunet 12y ago
    Not if you're a sculptor ;-)
    • dagw 12y ago
      I love that marble bust you just carved, it's perfect. Just one tiny little detail, could you just make about 30% larger?
      • Ygg2 12y ago
        Also, I'd like to half of the statue transparent and the other half in the form of a kitten? Oh and reflective. In red ink. https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
      • deleted 12y ago
        [deleted]
  • pjmlp 12y ago
    Have you ever tried to change enterprise software mid-flight?
• spc476 12y ago
  I could make the argument that source is the blueprint for a program. You use blueprints to know how to build a building, and you use source code to know how to build an executable, or rather, have a tool that automatically makes the program from the blueprint (source code).
• th3iedkid 12y ago
  Though the idea on specs vs proof systems is good enough , one of the reasons type systems are being studied is to actually make programming languages themselves a good proof system , so much so that DSLs themselves become the spec. Proof systems have their uses and then there are places where they are just too much.The best is in the mid! >> "am the creator of the TLA+ specification language." I think TLA+ is/was being used at Amazon [1] Safety with Preservation and Progress guarantees of critical systems demand design audits at a larger scale however if the scale of the program is actually quite small , things like type-systems themselves are sufficient proof of safety. Ofcourse there are cases where even typing is too much! One of the middlepaths is actually using inspection tools on code/programs as another aspect altogether. [1]:http://research.microsoft.com/en-us/um/people/lamport/tla/formal-methods-amazon.pdf http://research.microsoft.com/en-us/um/people/lamport/tla/fo...
• ori_b 12y ago
  While I do think proofs and planning are both useful, I think that the analogy doesn't work well. The process of producing code is the process of specifying what the computer should do -- the deliverable is the specification. On the other hand, few civil engineers will start designing plumbing without at least having a sketch of the floor plan and an idea of the building uses.
  • onion2k 12y ago
    The process of producing code is the process of specifying what the computer should do I'm sure coding is "specifying what the computer should do", but that's not what people are talking about when they talk about specifications. A specification defines what the application should do. Producing code is implementing the specification. Without having any specification first you wouldn't have a clue what the code needs to do, so you wouldn't know what to write. The problem with the analogy is that most people don't understand what a blueprint actually is. A blueprint is an architectural planning document. It defines the building in very broad terms - where the walls go, where there's a staircase, and so on. It doesn't go in to the detail of how the building is constructed. That comes from all the other documentation. As an analogy with software it's a pretty good one - a building's blueprint is equivalent to the high-level planning documentation that any big project needs.
• paulajohnson 12y ago
  I wrote a rebuttal of the "blueprints for software" analogy a couple of years ago. http://paulspontifications.blogspot.co.uk/2013/01/software-has-civeng-envy.html http://paulspontifications.blogspot.co.uk/2013/01/software-h... TL;DR: Source code is the blueprint for software. However that doesn't mean I completely disagree with Lamport's arguments. Specifications are necessary in large-scale software because otherwise you can't know if you have actually implemented everything the program is supposed to do. When you release it the end-users get angry and insist that they told you in that email / meeting / watercooler conversation last year how important it was that the program frobnicate the warbles. Lamport makes much of formal specifications. I agree that in some cases they do add value; trying to prove the correctness of a distributed protocol in any other way is dumb. But in my experience once you get up into application-level requirements a formal specification is basically source code you don't know how to compile; there is no formal correctness criteria against which you can verify it, and the stakeholders can't understand it in order to verify it.
  • onion2k 12y ago
    The "source code is the blueprint for software" analogy doesn't work because the source only tells you what the application does, not what it's supposed to do. There is no way to tell, from the source code alone, whether or not what's been built is fit for purpose. You have to have some other document. The "specification is the blueprint" analogy is saying that the specification is a high level document that sets out what the application is meant to do. As an example, imagine you're paid $1m to assess my super awesome new database. I give you the source code and tell you "the source is the blueprint." After reading through the code you discover there's no DELETE function. Have I built a clever immutable data store, or am I just an idiot who forgot a critical function? You can't tell that from the source.
    • lambeosaurus 12y ago
      I agree with you both. Technically the source is a blueprint. But this comes down to scale. Among other things I've worked on banking and corporate management applications. You cannot reason about the codebase at that scale. In these instances it's not possible to have a good outcome without a blueprint. Using the building metaphor, you can get away with building a bird feeder without a blueprint. You can't get away with building a skyscraper without one. Houses, maybe. Either way, high level blueprints help everyone.
• kitd 12y ago
  For those who may have found the linked article difficult to read, here it is neatly laid out (PDF): http://delivery.acm.org/10.1145/2740000/2736348/p38-lamport.pdf?ip=195.212.29.78&id=2736348&acc=OPEN&key=90259622823F2C32%2E97B4C8F68383D160%2E4D4702B0C3E38B35%2E6D218144511F3437&CFID=493697058&CFTOKEN=50811481&__acm__=1427704201_86137fab3766bc31f3fb4f1f24400798 http://delivery.acm.org/10.1145/2740000/2736348/p38-lamport....
  • badpenny 12y ago
    An error occurred while processing your request. Reference #50.cf633f17.1427707361.40a63048 Their error messages are as good as their typography.
    • virtualSatai 12y ago
      Try: http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-without-drawing-blueprints/pdf http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-hou...
      • RyanMcGreal 12y ago
        Here's the HTML version: http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-without-drawing-blueprints/fulltext http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-hou...
• WalterBright 12y ago
  Interestingly, blueprints are made in an iterative fashion much like software is.
  • cfontes 12y ago
    Yeah but they are done before you actually start to lay any bricks. In software you most of the time have the 2 things running parallel because of time constraints and other business needs, which almost always leads to failure.
• javindo 12y ago
  Somewhat off-topic anecdote on this: my father in law designed a very rough draft of "blueprints" for his parents new house in rural China (Xinjiang) using MS Paint, local labourers built it in a few months and it's still standing 10 years later!
  • hussong 12y ago
    From a European perspective, I like how you say that the house is still standing 10 years later (and someone in another comment above mentioned 25 years) like it's something outstanding. I would expect a house to last 100 years. A family member once bought a house that is over 400 years old (and still standing). Then again, construction and houses are way more expensive in Europe/Germany. They're planning to tear down and rebuild my old high school from scratch, current estimate: 85 million euros total.
    • maxerickson 12y ago
      It would be interesting to see a more rigorous comparison that took into account size and what not, but here's the first Google result for "new high school building", a $65 million project: http://www.monomoy.edu/page.cfm?p=931 http://www.monomoy.edu/page.cfm?p=931 (A regional high school school for about 700 students, 168,000 square feet)
• alvatar 12y ago
  It is very important to differentiate between House and Skyscraper. You can't build a skyscraper (currently) without blueprints. But you can, and it has been generally done, build houses without blueprints. It was even common to build cathedrals without formal blueprints, by the way. You can apply the same metaphors to software ;)
  • ams6110 12y ago
    I have built a house. You don't necessarily need professional blueprints but it's a good idea to at least have a scale drawing of your floor plan. Otherwise you won't really know how much of various building materials you will need. How many windows? What size? Where will they be positioned? Will they actually fit there? Also from a practical standpoint you probably won't be able to get a building permit without blueprints or drawings of some sort (though this varies).
  • gadders 12y ago
    What if someone else was building a house for you, rather than you building your own house? Wouldn't you like to know what you are getting?
• randartie 12y ago
  Higher quality version of this same talk (given at a different event): https://www.youtube.com/watch?v=-4Yp3j_jk8Q https://www.youtube.com/watch?v=-4Yp3j_jk8Q
• randartie 12y ago
  Higher quality version of this same talk (given at a different event): https://www.youtube.com/watch?v=-4Yp3j_jk8Q https://www.youtube.com/watch?v=-4Yp3j_jk8Q
• raverbashing 12y ago
  Same old waterfall crap? Thanks but no thanks
  • pjmlp 12y ago
    I guess you prefer the agile with certified scrum masters crap instead.
    • raverbashing 12y ago
      Yes I don't love it, but it works (better than the alternative) And we don't have any more weird conversations about trying to get the entire software, all the tasks, in one sitting.
      • pjmlp 12y ago
        Yeah, just weird conversations about when feature X is fully ready in which sprint, features that were done getting new "improvements" and getting sprints replanned in the middle of execution. Oh, and the famous feature requests disguised as bug reports for the features that didn't make it out of the backlog. I have done both ways and still haven't found a way to getting it working across the board with all parties.
        • raverbashing 12y ago
          It seems that those places are not taking Scrum seriously (as much as I hate this expression) > just weird conversations about when feature X is fully ready in which sprint, What stories compose that feature? How are you going to plan the following sprints? (are there other stories or only those?). Prioritize. > features that were done getting new "improvements" Yes, you can split stories into 2, or create a new story for something that you want changed/improved. Create a story, put it through the system and do it > and getting sprints replanned in the middle of execution. It happens. But it shouldn't be frequent. > Oh, and the famous feature requests disguised as bug reports for the features that didn't make it out of the backlog. Well, that's not really an Agile problem, that's scope creep (and shouldn't be allowed) It seems your problems are due to people implementing "half agile" or just using the buzzword without the important elements. Especially in small teams. (been there, done that)
• w4tson 12y ago
  TL;DR: The real problem to solve is the time to iterate. I think it's a straw man argument. An unfair comparison. Buildings & bridges etc have been designed and improved for literally thousands of years. Software is a half a century old. Aza Raskin's blog piece about human powered flight which bubbled up on HN has always stuck with me[0]. "The problem is we don't understand the problem". [0]: http://www.azarask.in/blog/post/the-wrong-problem/ http://www.azarask.in/blog/post/the-wrong-problem/
• fsloth 12y ago
  Once again I must refer to Naur's "Programming as theory building". Effectively programming is implementing a specific model. For the outcome at first release it does not matter how the model is documented - just that it is understood by the team. As time goes by, the more obscure the model is , the harder it is to maintain the understanding within the team. This probably one of the reasons some agile practitioners scoff at documentation - if one is using the same framework to implement the similar website time and again effectively the model remains the same and understanding of the model is easy to retain and retrain.
• fsloth 12y ago
  "Programmers spend a lot of time thinking about how to code, and many coding methods have been proposed: test-driven development, agile programming, and so on. But if the only sorting algorithm a programmer knows is bubble sort, no such method will produce code that sorts in O(n log n) time. Nor will it turn an overly complex conception of how a program should work into simple, easy to maintain code." This.
  • collyw 12y ago
    I wouldn't know a bubble sort off the top of my head (I haven't had to implement anything like that since university). I would know to read up on different algorithms and choose an appropriate library based on what I was sorting. (It will probably be better tested than what I would come up with first time).
• fsloth 12y ago
  This so much to the point as well: "The math needed for most specifications is quite simple: predicate logic and elementary set theory." I would take ABNF as used in RFC:s and a few clarifying diagrams over verbose UML vomit any day :)
• pjmlp 12y ago
  Fully agree with Leslie, coding as you go is fine for single coder projects or very small team with very talented developers. For anything of scale we really need blueprints.
• reitanqild 12y ago
  Seems smart but this > But few programmers write even a rough sketch of what their programs will do before they start coding. deserves a reference to a study. (or, and this is the first time I use this word: a #strawman flag.) - or am I the only one who sketches up data models and data flows before going to work? Also: Prototyping comes early in many other designs as well, often way before detailed blueprints are signed off I think (not a mechanical engineer, just outside observations). In software it just so happens that prototypes are often made by the same people and from the same material as the final product, only reinforced to withstand production load and abuse.
  • falcolas 12y ago
    > am I the only one who sketches up data models and data flows before going to work? Anecdata: Yes, or rather you're one of a vast minority. I work in an office with no notebooks in the supply closet, and one 5x5 whiteboard which is usually full of UX layouts.
• notacoward 12y ago
  What I've seen before, and seems to be the case in comments here, is that beliefs about programming methodology are heavily influenced by what kind of programming a person does. Those who work on small projects (i.e. few parallel streams of development) love their agile/scrum/whatever. Those who work on larger projects are less sanguine. Likewise, front-enders also love the hipper methodologies, while back-enders tend toward the old school, independently of whether their projects are large or small. The confounding case is the Linux kernel, which is both large and systems-focused but seems to eschew both kinds of methodology in favor of undirected chatter on mailing lists. Then again, maybe that's just part of a two-level process. More than a few patches to the kernel have real specs behind them, though developers don't call them that. They're just "kind of long, kind of detailed" emails. This tendency to embrace a thing while rejecting the term for it is one of the weirdest tendencies many developers seem to have.
• matt_s 12y ago
  I think the main thing missing in the discussion is organization or team size. Given that the author is a CompSci researcher for the past 40 years he may not be in touch with the reality of how organizations are structured and the impact of that on software development. If it is a start-up with 5 people, the software probably is the specification. If it is a large organization of devs (25, 50 or 100 people), then you will see more documentation, some of that specifications. There is likely a threshold in the number of people where the number of communication paths between them is too large to rely on informal ways of communication. Maybe its 15-25 developers. The larger an organization is the more bureaucracy gets introduced and you now have people whose role is to write specs and requirements docs, etc.
• JoeAltmaier 12y ago
  Off topic: my house was built without blueprints. Talked to the contractor, sketched what we wanted. He built it. Standing 25 years later, great job. An experienced carpenter/contractor can build a house, without excruciating detailed notes. In fact they can build it faster, adapting to conditions as they change and solving problems efficiently.