48 ms·

The separation of design and construction into phases is a hangover from civil engineering. It has the baked in assumption that the design phase is relatively c

The separation of design and construction into phases is a hangover from civil engineering. It has the baked in assumption that the design phase is relatively cheap, short and somewhat unpredictable the construction phase is expensive, long and predictable. The root problem is the assumption that specifications can be validated for correctness, like a blueprint for a bridge can. Nothing could be further from the truth. This is a persistent myth in software development.

HenryTheHorse 10y ago
> the design phase is relatively cheap In my world (enterprise software), the design phase is usually the most expensive phase, as it tends to be staffed with expensive architect/designer/technical lead-level folks.
mixmastamyk 10y ago
Yes, it is often (mostly?) true, but not always. In the book I've tried to not give the idea there is only one way to do things. Even so, a few have commented that they've got that impression. Also, from a practical standpoint, both the design and construction chapters are huge, so combining them doesn't seem to be a good idea. Perhaps I could add your warning though, if you don't mind me quoting you.
- nickbauman 10y ago
  I upvoted your comment even though (as a generalization) I disagree that these chapters should even exist as such. If were truly honest about the civil engineering metaphor as it applies to software, the design of a system is indeed the source code. The construction phase is done by the compiler. So your construction chapter should be about compilers and interpreters. Your design chapter should be about the explication of the stakeholder's intent in the form of human-readable code: the source code itself. What do you think?
  - mixmastamyk 10y ago
    Hmm, you've blown my mind. I've used traditional metaphors to describe and organize, such as the sdlc and topics like construction as defined by books like Code Complete. In other words, about/around these topics, not strictly limited to their concrete form or process. I suppose it isn't the only way to look at things, just common. Though we are approaching the philosophical realm at this point… reminds me of the section of Philosophy class where you learn to question if you can even trust your own senses. I'm not sure, however this is a book for beginners, and I sit on the shoulders of those that came before. Not sure I'm qualified to reimagine software engineering from the ground up as you describe. If you write that book, I'd read it!
    - lifeisstillgood 10y ago
      Try Jack Reeves from 93: http://www.mikadosoftware.com/articles/thecodeisthedesign http://www.mikadosoftware.com/articles/thecodeisthedesign I am also writing a "this much I know" style book, and would be very interested to hear your trials and tribulations I am very impressed you got from pile of notes to finished product - bravo.
      - mixmastamyk 10y ago
        Thanks, don't do it! Unless writing comes to you easily? The most depressing thing is "finishing" the book and then have to spend a month hacking css and build scripts to work around kindle bugs and the fascists at the ibooks store.
agentultra 10y ago
> The root problem is the assumption that specifications can be validated for correctness, like a blueprint for a bridge can. We can validate specifications for correctness with automated theorem proving! The least we can do is model-checking. At least for the hard algorithms and core system interactions. We've had this ability for decades. The problem with software development is that we get all hand-wavy about "architecture," and "design." I try not to physically groan when someone starts sketching out a box diagram. They're fancy pictures, sure, and useful at a conceptual level... but the reality is that the software will look nothing like that diagram. And there's no way to check that the diagram is even correct! Useless! It doesn't have to be painfully slow, burdensome, and expensive to employ these tools either. Contrary to popular belief it doesn't take a team of highly trained PhD physicists to build a formal mathematics for modelling computations these days. There are plenty of open-source tools for using languages like TLA+ that work great besides! Ask Amazon -- they published a paper about it. Watch Leslie Lamport - Who Builds a Skyscraper without Drawing Blueprints?: https://www.youtube.com/watch?v=iCRqE59VXT0 https://www.youtube.com/watch?v=iCRqE59VXT0
- 2muchcoffeeman 10y ago
  I draw pictures because I think in pictures. I just took a short look at TLA+ and read a tutorial. Don't think I could use it without drawing a picture.
  - agentultra 10y ago
    Drawing a picture is a perfectly valid and legitimate start. However I think there are many problems where a picture is not sufficient and it's necessary to have good, reliable mathematics to sketch out our designs and prove properties of them. A sketch is still useful the the absence of nothing else. But we don't build bridges and skyscrapers that way so why is it good enough for our data-centres and applications? I don't think lives have to be on the line in order for software to be considered harmful if not built correctly. There are plenty of problems where having a thoroughly checked design will save you plenty of headaches and afford you many more opportunities.
amelius 10y ago
> The separation of design and construction into phases is a hangover from civil engineering. Yes and it is a pretty good principle. The last thing you want in a software project is a design which changes all the time.
- nickbauman 10y ago
  Except a design that doesn't change after a certain arbitrary phase of a project simply guarantees your best outcome will be to deliver what the customer said they wanted once upon a time.

HenryTheHorse 10y ago

> the design phase is relatively cheap In my world (enterprise software), the design phase is usually the most expensive phase, as it tends to be staffed with expensive architect/designer/technical lead-level folks.

mixmastamyk 10y ago

Yes, it is often (mostly?) true, but not always. In the book I've tried to not give the idea there is only one way to do things. Even so, a few have commented that they've got that impression. Also, from a practical standpoint, both the design and construction chapters are huge, so combining them doesn't seem to be a good idea. Perhaps I could add your warning though, if you don't mind me quoting you.

nickbauman 10y ago
I upvoted your comment even though (as a generalization) I disagree that these chapters should even exist as such. If were truly honest about the civil engineering metaphor as it applies to software, the design of a system is indeed the source code. The construction phase is done by the compiler. So your construction chapter should be about compilers and interpreters. Your design chapter should be about the explication of the stakeholder's intent in the form of human-readable code: the source code itself. What do you think?
- mixmastamyk 10y ago
  Hmm, you've blown my mind. I've used traditional metaphors to describe and organize, such as the sdlc and topics like construction as defined by books like Code Complete. In other words, about/around these topics, not strictly limited to their concrete form or process. I suppose it isn't the only way to look at things, just common. Though we are approaching the philosophical realm at this point… reminds me of the section of Philosophy class where you learn to question if you can even trust your own senses. I'm not sure, however this is a book for beginners, and I sit on the shoulders of those that came before. Not sure I'm qualified to reimagine software engineering from the ground up as you describe. If you write that book, I'd read it!
  - lifeisstillgood 10y ago
    Try Jack Reeves from 93: http://www.mikadosoftware.com/articles/thecodeisthedesign http://www.mikadosoftware.com/articles/thecodeisthedesign I am also writing a "this much I know" style book, and would be very interested to hear your trials and tribulations I am very impressed you got from pile of notes to finished product - bravo.
    - mixmastamyk 10y ago
      Thanks, don't do it! Unless writing comes to you easily? The most depressing thing is "finishing" the book and then have to spend a month hacking css and build scripts to work around kindle bugs and the fascists at the ibooks store.

agentultra 10y ago

> The root problem is the assumption that specifications can be validated for correctness, like a blueprint for a bridge can. We can validate specifications for correctness with automated theorem proving! The least we can do is model-checking. At least for the hard algorithms and core system interactions. We've had this ability for decades. The problem with software development is that we get all hand-wavy about "architecture," and "design." I try not to physically groan when someone starts sketching out a box diagram. They're fancy pictures, sure, and useful at a conceptual level... but the reality is that the software will look nothing like that diagram. And there's no way to check that the diagram is even correct! Useless! It doesn't have to be painfully slow, burdensome, and expensive to employ these tools either. Contrary to popular belief it doesn't take a team of highly trained PhD physicists to build a formal mathematics for modelling computations these days. There are plenty of open-source tools for using languages like TLA+ that work great besides! Ask Amazon -- they published a paper about it. Watch Leslie Lamport - Who Builds a Skyscraper without Drawing Blueprints?: https://www.youtube.com/watch?v=iCRqE59VXT0 https://www.youtube.com/watch?v=iCRqE59VXT0

2muchcoffeeman 10y ago
I draw pictures because I think in pictures. I just took a short look at TLA+ and read a tutorial. Don't think I could use it without drawing a picture.
- agentultra 10y ago
  Drawing a picture is a perfectly valid and legitimate start. However I think there are many problems where a picture is not sufficient and it's necessary to have good, reliable mathematics to sketch out our designs and prove properties of them. A sketch is still useful the the absence of nothing else. But we don't build bridges and skyscrapers that way so why is it good enough for our data-centres and applications? I don't think lives have to be on the line in order for software to be considered harmful if not built correctly. There are plenty of problems where having a thoroughly checked design will save you plenty of headaches and afford you many more opportunities.

amelius 10y ago

> The separation of design and construction into phases is a hangover from civil engineering. Yes and it is a pretty good principle. The last thing you want in a software project is a design which changes all the time.

nickbauman 10y ago
Except a design that doesn't change after a certain arbitrary phase of a project simply guarantees your best outcome will be to deliver what the customer said they wanted once upon a time.