1. 3
  1.  

  2. 12

    Requirements change. Every software engineering project will face this hard problem at some point. […] With this in mind, all software development processes can be seen as different responses to this essential truth. The original (and naive) waterfall process simply assumed that you could start with a firm statement of the requirements to be met.

    This isn’t something unique to software. I’ve talked with at least two civil engineers who had to move bridges because the requirements changed after they were built.

    1. 6

      Yes, the whole article is rehashing the “Agile” argument without anything of substance.

      My father has worked in construction for nearly 50 years, and I did as well for a few. Requirements and environment conditions always happen. What good construction and engineering firms do is seriously account for that. The guys who lowball a bid inevitably run over cost and time by significant amounts. Sadly, clients fall for the lowball bids too often.

      1. 3

        And they get what they pay for. Probably.

      2. 1

        Wasn’t waterfall the “do not do this” example in the paper that coined the term?

        1. 1

          Are these stories published somewhere?

          Lots of developers are under the impression that civil engineers don’t have to deal with crazy requirements changes. Examples on orange site:

          And no civil engineer will ever have to deal with the update to Gravity 2.0 now even better at 10m/s2

          Also a civil engineer usually understands exactly what the bridge is supposed to do and how it is going to be used.

          there’s a mutual agreement that such change comes with significant cost, and it’s this part that is missing in the software world.

          Everything about a bridge is planned in extreme detail before work on the ground ever starts. This level of planning is absent in software.

          client needs are easy to transport into the mind of [a civil engineer]

          1. 3

            I’m working on it! This is part of a broader project where I interviewed a bunch of people who worked as both “trad” engineers and software engineers to figure out how they’re actually different. Most software engineers don’t actually know what trad people actually have to deal with and are working on stereotypes.

            And no civil engineer will ever have to deal with the update to Gravity 2.0 now even better at 10m/s2

            Here’s a page on how individual screws can wildly vary in terms of structural strength: https://www.fastenal.com/en/76/metric-system-and-specifications.

            And here’s one on how mixing aluminum and steel bolts can corrode the bridge! https://www.fastenal.com/en/70/corrosion

            Also a civil engineer usually understands exactly what the bridge is supposed to do and how it is going to be used.

            What about electrical engineering? Chemical engineering? Off-the-shelf integrated circuits? Mines?

            there’s a mutual agreement that such change comes with significant cost, and it’s this part that is missing in the software world.

            Not really, stuff changes all the time.

            Everything about a bridge is planned in extreme detail before work on the ground ever starts. This level of planning is absent in software.

            As one oil rig engineer told me: “we file three blueprints: what we originally planned, what we ended up building, and how we kludged it after we built it.”

            client needs are easy to transport into the mind of [a civil engineer]

            See above.