1. 8
  1.  

  2. 6

    PS This is all just to say that app-making is nothing like building a house. It’s more like building the first house ever in the history of houses, with a pile of rusty nails and your bare hands, in a non-stop tornado. It’s different every time, and it’s astonishingly complex, non-linear, and unpredictable. We all do our best to mitigate this, to make it more regular, but the industry just hasn’t gotten very far with that yet. The only reason anything ever ships is because people just keep working until it’s ready.

    This person has never built a house.

    I’ve talked to actual architects and they say construction is nothing like this stereotype. They find it rather condescending. I’ve also talked to people who have worked professionally as both architects and programmers. They say the same thing.

    Everybody who says “software is more special than X!!!” inevitably gets the most basic facts about X wrong.

    1. 4

      There’s this widespread and unfortunate tendency towards hyperbole, which obfuscates and devalues the underlying critique. My guess is it’s written in a “blowing off steam” mode, rather than to articulate, analyze, or even persuade.

      But I have worked in both construction and building maintenance. My dad was a general contractor. I think there are some important differences between how buildings and software get designed and built, and you don’t need three exclamation marks to highlight them either. To start with, buildings have permits and building codes. Mechanical and civil engineers, as well as architects, have professional societies and mandatory accreditation processes. The building trades have licensing processes, apprenticeships, and in some cases unions.

      1. 4

        I have built houses. Building houses and building software have so many overlaps they might as well be the same industry.

      2. 4

        I think it’s interesting, but a bit unfortunate that this article is really making two very distinct points without clearly separating them:

        1. You can’t estimate how long it will take to implement any particular functionality.
        2. You shouldn’t promise ETAs because your priorities might change, or other work might arise that’s more important.

        I’m not sure the two points have anything in common except a shared pessimism/get off my backness (“mood affiliation”). Even if we could estimate each feature without near perfect accuracy, 2 could be true for any features that aren’t in the extreme short-term.

        1. 3

          Maybe, after a few more centuries of practice, our discipline will be rich enough to give detailed estimates of how long a computation or programming task ought to take. But I agree that, at the present, it’s irresponsible to give estimates without some underlying formalism, and most software development is depressingly informal.

          1. 0

            Will formalism actually help? Indeed, you might summarize the classical Halting Problem as “it’s impossible to give an accurate estimate for when an arbitrary completely-formalized task will be completed, or even if it ever will”.

            1. 5

              Could you, working by yourself full time, recreate all the functionality on lobsters within, hmmm, 20 years?

              There you go, an accurate estimate: it will take you at most 20 years to recreate lobsters. It’s not precise, but it’s certainly accurate!

              The hard part is being both precise and accurate. But it’s not uniquely more difficult for software than, say, designing a building or planning new bus routes or drafting new public policy. There are some things that make it different, but there are some things that make traffic control different, too. If we can’t estimate software, then we can’t estimate anything.

              1. 2

                I agree. The halting problem thing is, like so much theory, not exactly practical.

                I think it’s generally worse for software (relative to construction and policy, your examples) mostly because we lack standardized and trustworthy domain knowledge and practices.


                Edit: 20 years? Really? I dunno.. I might die first, or just give up. Halting problem!

                1. 2

                  Lobsters already exists, which means that “recreate Lobsters” is known to be possible. That’s like asking if a program halts after it has already halted.

                  You want something more difficult to estimate, find an industry that employs people to do paperwork, and replace them with a software system. That kind of situation gives you the chance of actually failing.

                  1. 3

                    Halting problem isn’t about any program halting, it’s if an arbitrary program can halt. There are classes of programs we can tell if they halt or not, same as we can estimate certain projects very well.

                    Replacing paperwork is more difficult to estimate as a software project. But you know what’s also difficult to estimate? Building a house in a new environment with unfamiliar constraints when new regulations are on the horizon. Software isn’t special!

                    1. 1

                      But you know what’s also difficult to estimate? Building a house in a new environment with unfamiliar constraints when new regulations are on the horizon.

                      So physical architecture is equivalent to running an arbitrary program? Fine. It’s also impossible to compute how long it will take, or if it will complete at all, in the general case. You might be able to estimate some problems, but no process can give accurate predictions for all of them.

                      “Software is special” and “estimation is impossible” are completely separate claims.

                      1. 1

                        Fine. It’s also impossible to compute how long it will take, or if it will complete at all, in the general case. You might be able to estimate some problems, but no process can give accurate predictions for all of them.

                        What do other fields do? If Software Isn’t Special, and other fields have ways of getting around the difficulties of estimating, then there are probably ways we can make better estimates, too.

            2. 1

              Aren’t there some people, somewhere, who work in reasonably well defined and unchanging environments? Isn’t it at least theoretically possible to engineer out a whole bunch of these soft variables? How does NASA do things these days?

              1. 4

                NASA (and ESA, and Roskosmos, and JAXA…) constantly miss their ETAs and run over budgets. And since the house building analogy is even more true for them, it’s not surprising.

                1. 4

                  NASA isn’t unusual for its ability to deliver on time and budget, it’s unusual for its ability to create computing systems reliable enough to put in spacecrafts. They can achieve this because they can absorb a level of cost of development that (for better or for worse) no business would tolerate.

                  In the context of the article linked here, NASA is not a relevant example.