|The stupid question is the question not asked|
Re^12: Beyond Agile: Subsidiarity as a Team and Software Design Principleby BrowserUk (Pope)
|on Jul 23, 2015 at 06:02 UTC||Need Help??|
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.
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!