1. 17
  1.  

  2. 9

    I feel like a jerk saying this… but why do we think software should be “done”? We don’t seem to harbor the same illusion about other business practices. If something in our environment renders any other business practice ineffective or obsolete, we alter the practice and for the most part don’t whine about how onerous that is.

    Maybe the problem is that we’re looking at software as if it were a thing instead of a codified and automated set of processes and procedures. We should stop that, because that expectation is making it harder for us to allocate our resources and react to changes in our environment.

    I don’t think I”m being a jerk or a curmudgeon right now, but I would concede the point if someone told me I sound like one.

    1. 5

      If something in our environment renders any other business practice ineffective or obsolete, we alter the practice and for the most part don’t whine about how onerous that is.

      This is incorrect–examples being SAP, the MPAA/RIAA and abuse of copyright, or the use of DUNS numbers, or any of another dozen things. Whining is in fact so common that there is an entire industry for it: lobbying.

      but why do we think software should be “done”?

      Because a program is ultimately math, and math shouldn’t change. Software is ultimately an artifact made of information, and as such should still be usable well after the artificers have passed–provided we still can decode the information.

      1. 4

        Whining is in fact so common that there is an entire industry for it: lobbying.

        Good point. I feel like the kind of whining I hear about software is qualitatively different in a way that I have a hard time describing right now, but you’re exactly right here.

        Because a program is ultimately math, and math shouldn’t change.

        Eehhhhh… I’d argue vigorously that a program is ultimately applied math. While the math itself shouldn’t change, the application (and the wisdom of said application) differs greatly depending on the environment. It lets us use math to automate the application of business rules, often at much lower cost or larger scale than we could without its assistance. Automating the application of the math lets us screw up faster and bigger if an assumption underlying the correctness of that application turns out to be wrong.

        Maybe it’s that error amplification alongside the notion that math shouldn’t change, that makes the need to maintain software so surprising for so many.

        1. 7

          Because a program is ultimately math, and math shouldn’t change

          This has to be the dumbest thing I’ve read in a long time. Programs are not math, they are instructions. Maths exist to describe how reality works. Programs exist for the exact opposite purpose, which is to effect change in reality.

          1. 1

            I would suggest friendlysock means something like a program is f(x), and always returns the same output for some parameters x. To me, at least, software development is about deriving the correct function for some set of parameters, which is a definite point of completeness.

            1. 2

              This is only true for pure functional programming languages, which are themselves emulated on Von Neumann architecture with an “instruction set” that has all kinds of side effects. So in a practical sense, Computer Software and Math are not the same thing, and we have yet to build a true functional machine.

              1. 1

                That’s not the case. Surely you can think of how any program, for identical inputs (including environment etc) returns the same (correct) output each time

                1. 4

                  For any inter-networked system, saying something like “assume completely identical inputs, including the environment” feels quite a bit like saying “assume a frictionless and massless pulley.”

                  I’m not dismissing the usefulness of making either assumption as a reasoning tool, but both require assuming something you know to be untrue, and betting that the discrepancy doesn’t matter to your problem.

                  1. 2

                    This makes sense to me if one considers these as additional program inputs:

                    • the current date/time
                    • the version of the database driver
                    • the number of users simultaneously using the system
                    • the time zone which the current user is in
                    • the current user’s internal ID, or name, or settings, or browser cookies, or…
                    • etc
          2. 2

            I see what you mean, but other feats of engineering are “done” at some point, and go into a much lower-maintenance mode. Once a bridge is built, it is monitored for repairs, but the construction company doesn’t sit on the bridge and constantly “iterate” on its design.

            1. 4

              I think part of the problem here is how different software engineering is from other engineering disciplines. The vast bulk of software products aren’t built with the same kind of rigor that goes into building a bridge. There are elements of mathematics and the like, but once business and legal requirements get involved the discipline starts to have too much in common with things like law. The target moves a lot faster than the transition from e.g. bridges for horse-drawn carts to bridges for large trucks. On top of that, it gets a lot harder to develop the kinds of techniques, tests, and so on that enable designing a bridge without having to derive everything from first principles.

              I’m not an engineer though, so happy to be corrected. I could just be romanticizing the world of civil engineering etc.

              1. 4

                Software engineering is really not that unique. There are some things we have that are different, like incredibly fast feedback loops and a lack of physical uncertainty, but overall we share a lot more in common with other engineering disciplines than we have that’s different.

                1. 1

                  I’ll trust you on that, then. I think the lack of rigor is true, but maybe there’s no good, principled reason why software engineering hasn’t caught up in that regard.

              2. 4

                Chemical engineers are constantly tweaking their process flows. Chemical engineering is never done.

                1. 2

                  but other feats of engineering are “done” at some point, and go into a much lower-maintenance mode. Once a bridge is built, it is monitored for repairs, but the construction company doesn’t sit on the bridge and constantly “iterate” on its design.

                  A bridge is also vastly less complex, with much simpler requirements, and operates on much simpler and better-understood engineering principles.

                  And bridges can run in to trouble too if requirements change; quite a few bridges were built with just cars in mind, and retrofitting them with pedestrian/bike lanes doesn’t always work all that well.

                  Also maintenance costs may be higher than you’d expect; the Clifton bridge in Bristol for example, completed in 1864, costs about £1 million/year in maintenance, which excludes £8 million in various structural repairs that need to be done.

                  1. 1

                    A bridge is also vastly less complex, with much simpler requirements, and operates on much simpler and better-understood engineering principles.

                    Bridges are much more complicated than you think.

                  2. 2

                    Not only that, but when it comes time to re-paint, you don’t have to rebuild the entire bridge because the company that built the coffee pots in the engineering room went out of business.

                    1. 5

                      On the other hand, when you get a new piece of equipment for the oil rig that’s too tall for the floor, you have to raise a small section of the ceiling by one foot, and then everything on the floor above has to be reconfigured around that, and then you have to live with the oil rig having a raised section of the floor forever.

                      Source: an oil and gas engineer I interviewed

                2. 2

                  There is another slightly different viewpoint that I prefer to the OP here which is talked about here and called:

                  A culture of stability and reliability

                  I find there’s nothing wrong with software that changes, but one should be mindful of managing that change over time. Software can reach a point of “stability”, but I do not believe software can ever be truly “done” in any sense of the word except for the most trivial examples, e.g: print/display “Hello World”.

                  1. 1

                    Interesting question. It sounds a bit like schema migration on a code level. Smalltalk migrates live objects to updated class definitions (called object schema migration).

                    Bumping a patch or minor dependency upgrade is fine, but a major one with breaking API changes tends to need a human to get involved. Why?

                    Take this API update: f(x) is deprecated. You can replace it with g(x,z) where z is an instance of interface A. To get a tool to do the migration automatically, it not only needs to understand the API change but also it needs to understand how to pass the right object for z. It feels like an AI problem.

                    edit: give a harder example