But software doesn't exist alone. No piece of software operates in a purely static isolated world.

Human requirements change. Technological requirements change. The software you wrote on Windows maybe now has to support Linux. So the software you speak of is an abstraction which has very little real-world meaning.

With bounded responsibilities, the team which built the software is likely to have the responsibility of maintaining it after release.

The brutal fact of the matter is that we are all in the business of constructing software mechanisms which will be executed by a silicon chip smaller than our pinky fingernail ... and beyond our direct control.

But there is no difference in kind to building a hammer. Suppose I make and sell hammers. That will be used for things outside my direct control. In fact, the team that designs and builds these will have *less* control than the software developer has. The control issue is not specific to automation.

Also I am not entirely sure that automation should remove the human from the process. There is a lot of research going on right now in things like avionics about how to bring humans back into the process more. And in areas where I work (including financial software), humans need to be in control. So the automation there ends up being less like a robot (something that fully automates tasks) and more like a hammer (something we use to enhance our own working capabilities).

“Because you are building: a machine.”

This is, by far, the stupidest thing -- amongst a very long list of very stupid things -- that you've said here. (And repeated ad nauseum.)

• Machines don't make decisions; software does.
• Machines do not adapt to their inputs; software does.
• Machines do not prioritise their responses to inputs; software does.
• Machines have physical limitations; software has only logical limitations.

Bottom line: Software is to hardware as pheromones are to ants.

The book may be good -- or not -- but your over-literal interpretation of it is crap.

Machines don't make decisions; software does.

Define "decision." I don't see a principled line between the sorts of decisions that software can make and those a physical machine can make. Consider for example, the old electromechanical phone switches....

Machines do not adapt to their inputs; software does.

Again I am not sure what this means. Maybe it could use more explanation?

Machines do not prioritise their responses to inputs; software does.

Why not? Certainly I could imagine a machine which would prioritize processing of inputs.

Machines have physical limitations; software has only logical limitations.

I think I get what you are saying here but I am not sure what relevance it has. Certainly the system running the software has physical limits. So software is a sort of abstraction and being an abstraction allows us to think about it disregarding the limits (I think that's dangerous though). But I think there are also human limits to software and because software is an abstraction we don't tend to talk about those.

Bottom line: Software is to hardware as pheromones are to ants.

That's actually a good analogy. I like it. But pheramones are subject to physical limits (temperature, air characteristics) etc. right? ;-)

1. Machines don't make decisions; software does: ... Consider for example, the old electromechanical phone switches....

   The only decision being made there is by the human being that dials the numbers. They dial 9; nine pulses are generated by the dial; those nine pulses cause the switch to rotate 9 places.

2. Machines do not adapt to their inputs; software does: Again I am not sure what this means.

   If the pilot of a pre-fly-by-wire airliner dies at the stick and slumps forward on that stick, the plane will inevitably nosedive.

   With fly-by-wire airliners, the flight control software can and does intervene and disregard pilot inputs that take the aircraft outside of its safe flight envelope.

3. Machines do not prioritise their responses to inputs; software does: Why not? Certainly I could imagine a machine which would prioritize processing of inputs.

   Then I invite you to publish your imaginings of a purely mechanical system for applying the brakes on a car if it detects a human being in the vehicles path.

4. Machines have physical limitations; software has only logical limitations: I think I get what you are saying here but I am not sure what relevance it has.

   From Nancy G. Leveson. Aeronautics and Astronautics.MIT:

   Software is pure design without any physical realization and therefore “fails” only by containing systematic design defects. In fact, software can be thought of as design abstracted away from its physical representation, that is, software (when separated from the hardware on which it is executed) is pure design without any physical realization of that design. While this abstraction reduces many physical limits in design and thus allows exciting new features and functions to be incorporated into spacecraft that could not be achieved using hardware alone, it also greatly increases potential complexity and changes the types of failure modes. With respect to fault tolerance, potentially unsafe software behavior always stems from pure design defects so redundancy—which simply duplicates the design errors—is not effective. While computer hardware reliability can depend on redundancy, dealing with software errors must be accomplished in other ways.

   The recent SpaceX Falcon 9 mid-air explosion was caused by the failure of 2ft long, 1" diameter steel strut. Rated for 10,000lbs, it failed at 2,000lbs. The fix is relatively simple; redesign the strut to increase its strength and test each one individually before flight. It took them 3 weeks to find that physical error.

   Contrast with the life, path and root cause of a software error:

   There was, however, a potentially serious software error that occurred in April 2009, just two years before the Shuttle’s retirement. The error manifested itself in flight STS-126 a few minutes after Endeavor reached orbit. Mission Control noticed that the Shuttle did not automatically transfer two communication processes from launch to orbit configuration mode. Mission Control could not fix the problem during the flight so they manually operated necessary transfers for the remainder of the flight. The pathway for this bug had been introduced originally in a change made in 1989 with a warning inserted in the code about the potential for that change to lead to misalignment of code in the COMPOOL. As more changes were made, the warning got moved to a place where it was unlikely to be seen by programmers changing the code. The original change violated the programming standards, but that standard was unclear and nobody checked that it was enforced in that case. Avoiding the specific error that was made was considered “good practice,” but it was not formally documented and there were no items in the review checklist to detect it. The SPF did not identify the problem either—testers would have needed to take extra steps to detect it. The SAIL could have tested the communication switch but it was not identified as an essential test for that launch. Testing at the SAIL did uncover what hindsight indicated were clear problems of the communication handover problem, but the test team misinterpreted what happened during test—they thought it was an artifact of lab setup issues—and no error reports were filed.

Comparing software to a machine at anything more than a totally superficial level, completely misrepresents the nature and complexity of software.

This is a complex machine, but it is roughly equivalent to 10 lines of Perl.

---

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!

The monk monks that upvoted this should be ashamed.