Re^12: Beyond Agile: Subsidiarity as a Team and Software Design Principle

[BrowserUk]

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.

[einhverfr]

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.

[Anonymous Monk]

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

[einhverfr]

If I understand you correctly you are making a "More is Different" kind of argument. I.e. software cannot be reduced to applied hardware. And at least in some areas I agree. Hardware and software are different abstractions for different domains. Software is not merely applied hardware just as chemistry is not merely applied atomic physics and biology is not merely applied chemistry.

My doubt though is with the specifics. Chemistry derives some important properties from atomic physics, and software derives important properties, including limits, from hardware. In other words software will always be physically limited by hardware and by important other physical limits (for example the CAP Theorem becomes a physical limit when you are talking about physically separate systems). We think about logic problems and decision trees in different ways.

So what I am getting at is that there is a lot to be gained at looking at software from a software-as-machine perspective. There is a lot of insight that can be gained there. I think you and the other poster (the "Managing the Mechanism" guy) are arguing about how it is different. I am not convinced that either of those sets of differences hold up. I think no software plays the game itself (that's a fantasy), but also software is not unlimited either by logic or by the physical world. Rather the differences are differences in abstractions we come up to manage the differences in complexity.

An example might be quantum physics -> solid state electronics -> integrated circuits -> chip architecture. Each of these disciplines invents additional abstractions to deal with the complexity and changes in behavior found. But if you want to really understand one level you would do well to become reasonably competent at the level immediately underlying it.