in reply to Re^10: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

I guess what I am not sure about is whether those are really differences in kind or just degree. Let's take for example a WWII-era torpedo. It is effectively programmed mechanically without software. It cruises at a given depth and under certain inputs decides to explode. Similarly unmanned cruise missiles have been around with similar criteria longer than we have thought about these things in terms of software.

It is true that software allows these decision trees to be more complex than one gets with purely mechanical systems but prioritizing inputs is a basic strategy in safety engineering. You might have a riding lawn mower disengage the blades when the rider stands up for example. On the other hand, if the pilots die in a modern fly by wire airplane, it will still eventually crash just later (see Helios Airways 522). To a certain extent you have significant issues with human troubleshooting and highly automated systems (see this article in IEEE Spectrum) because of complexity but I am not sure how software makes that significantly worse directly other than just increasing complexity.

The software you speak of is an abstraction that doesn't exist in the real world. A more realistic view of software is that it provides a mechanism to adapt machines to changing needs. If we are going to disregard speed there's no real reason that electro-mechanical systems could not do anything electronic systems can, just slower and if speed is a criteria you are limited to the physical requirements of the systems today.

This is also where my disagreement with the guy promoting that book is, namely that software exists in a context, teams don't just go home (someone has to maintain and manage the machine). Software in the real world doesn't just run itself.

  • Comment on Re^11: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^12: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by BrowserUk (Patriarch) on Jul 23, 2015 at 06:02 UTC
    It is true that software allows these decision trees to be more complex than one gets with purely mechanical systems but prioritizing inputs is a basic strategy in safety engineering

    From my perspective, you've made my argument for me with that statement.

    WWII torpedos (non-wire guided) used a gyroscope to get them to run in a straight line. The trick to getting them to hit the target was to launch them on the right course. Calculating that course was a matter of solving an equation, which was done using either a slide rule, or later and electro-mechanical computer, that "required two extra crewmen: one as an expert in its maintenance, the other as its actual operator.".

    That same equation could again be solved with 10 or 20 lines of Perl. The job of that electro-mechanical computer could today be performed by the same disposable chips that you find in musical greetings cards for a couple of quid.

    A modern torpedo "can also use their own active or passive sensors to execute programmed target search, acquisition, and attack procedures. The torpedo is designed to detonate under the keel of a surface ship, breaking the ship's back and destroying its structural integrity. In the event of a miss, it can circle back for another attempt.".

    It simply wouldn't be possible to construct a purely mechanical system equivalent to this; but if is was, the torpedo would need to be the size of nuclear sub in order to house the all the gears and motors; and probably still wouldn't have room for a warhead.

    And that's it. Even the simplest of software systems contains the equivalent of millions upon millions of mechanical parts.

    By the time you get to something like the browser you are using to read this with its ability to be programmed in multiple different languages -- html/xml/css/javascript -- display and process images, video, vector graphics; communications; encryption/decryption; etc. etc. It is more complex than even the most complex machines. If you add in all the subsystems of the operating system; communications stacks; device drivers; etc. required to allow it to run, you've upped that complexity by another order of magnitude or two. Factor in all the ways and timings those different subsystems interact and you've upped the ante again.

    If you're going to compare software to hardware, you shouldn't compare it to "a machine"; but rather something like a large car or aircraft production plant; where you have 1000s of machines all interacting and working in concert. Only then do you begin to approach the same levels of complexity as even a fairly modest software system. And for the largest software systems you need to be thinking in terms of something like all the machines and systems in a large town or small city.

    But complexity is only one of the 4 major differences between software and hardware I listed above.

    Another that I didn't get to: these days when designing a building; or a ship; or a bridge; or a car or aircraft; or any other complex mechanical engineering project; we use computers to do it. We protect entire buildings/ships/planes in transparent 3D images that we can walk around, zoom in, check for clearances and paths; even light levels, acoustics and aesthetics.

    Despite that we use computers to write software -- editors, compilers, VCS etc. -- we still essentially write code by hand; and write the code that tests the code by hand. We don't have the equivalent of CAD/CAM or even the equivalent of simple gauges that can quickly, accurately, repeatedly and definitively test a mechanical engineers work.

    We've succeeded in working out how to apply software to assist in doing (or even do) almost every other type of work; but we've yet to even begin to apply it to the task of constructing software. I think there is a good reason for that; and it isn't because were protecting our jobs.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
    I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]

      I am still not convinced this is a difference of kind. It still looks like a difference in degree. I.e. more complexity rather than a different kind of complexity. Not all torpedos were purely gyroscopic. Depth sensing was accomplished, for example, with pneumatic bladders.

[reply]

        I am still not convinced this is a difference of kind. It still looks like a difference in degree. I.e. more complexity rather than a different kind of complexity. Not all torpedos were purely gyroscopic. Depth sensing was accomplished, for example, with pneumatic bladders.

        Ah, the complexity of pneumatic bladders, now there is a machine that will take over suffocate the world :P

[reply]

In Section Meditations