Skip to main content
Disciplines
Automotive Business IT + Informatics Construction + Real Estate Electrical Engineering + Electronics Energy + Sustainability Insurance + Risk Finance + Banking Management + Leadership Marketing + Sales Mechanical Engineering + Materials
Events
DE
EN
Books
Journals
Topic Page
Marketing
Start single access now
Access for companies
EXTENDED SEARCH
Log in
Top

2011 | Book

Introduction Read chapter Read first chapter

The Seductive Computer

Why IT Systems Always Fail

Author: Derek Partridge

Publisher: Springer London

Part of: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Login to get access
insite
SEARCH

About this book

IT systems explode budget estimates, bust production deadlines by years, and then fail to work properly. Why this IT-system crisis? Poor programmers? Inadequate project management? No.

The Seductive Computer argues that the fundamental nature of programming technology itself is the real culprit; it promises perfection but can only deliver emergent chaos. It is also an insidiously compelling technology, peculiarly male oriented.

IT systems, an unavoidable and increasing reality in all our lives, are something new to man - large-scale discrete complexity. The Seductive Computer explains this novelty that defies human understanding.

This book illustrates in a simple yet thorough manner the underlying concepts necessary for understanding the IT-system crisis - not ‘How To Program’ but what the demands of programming are. It then proceeds to lay out the full gamut of issues - all stemming from the nature of the technology.

From development to maintenance IT-system personnel are grappling with incipient chaos. The technicians are seduced by the detailed challenge of the technology. The scientists are seduced by the promises of their technology. The managers and users are seduced by the mysteries of the technology. No IT system is ever fully understood by anyone, so surprising behaviours will always emerge.

What can be done? We must rein in our expectations of IT systems: what they can do, and how reliably they can do it. On the positive side, The Seductive Computer discusses novel paradigms that look beyond the current discrete technology: neural computing and precise approximation computing.

Table of Contents

Frontmatter
Chapter 1. Introduction
Abstract
IT systems are everywhere, and will continue to infiltrate the lives of all of us. We cannot easily check that an IT system is computing correctly. IT systems all fail: sometimes immediately and spectacularly, sometimes unobtrusively just once in a while, and sometimes in any combination of these two extremes. IT-system failures vary from production of blatantly incorrect results to failure to produce a desired result. The interplay of a variety of causes means that all large IT systems are unmanageably complex. IT-system complexity is discrete complexity rather than complexity based on continua. If, by chance (combined with exemplary practice and much effort), an IT system is constructed with no possibility of failure behaviour, we can never know this. The fundamental problem is the nature of the technology used.
Derek Partridge

The Joy of Programming

Frontmatter
Chapter 2. The Happy Hacker, Love at First Byte
Abstract
To some, programming is an alluring man-machine tussle that ultimately promises to put great power in the hands of the man. The first challenge (the easy one) is that a program must be grammatically correct before a computer will accept it. But the (much) bigger challenge is getting an accepted program to cause the computer to behave in precisely the way you want it to behave; does it behave correctly? In programming (almost) anything is possible, if you are smart enough. Who can resist that challenge, especially when the tussle is totally private?
Derek Partridge
Chapter 3. The Reluctant Programmer
Abstract
We go through the basics of programming technology: a computer program is a list of instructions, each selected from a programming language, that tell the processor to manipulate symbols (in our case, to add and multiply numbers) and what storage boxes of the memory to put the results in. Once your program is accepted as grammatically correct, the computer will execute it, and the behaviour it specifies will emerge; a behaviour that depends on the precise order of the instructions. Programming thus demands a high proficiency in all-round trivia management (from instruction order to storage-box naming). The instruction sequence dictates a flow path through the program, i.e., the order in which the computer will execute each instruction. The resultant emergent behaviour may be correct, i.e., what you intended, or incorrect, not what you intended. But even when the snippets of observed behaviour look to be correct, the full details of the causal links between correct behaviour and your intentions are hard to verify. So, general correctness of IT-system behaviour will remain a faith-based property.
Derek Partridge
Chapter 4. Cooking Up Programs
Abstract
Through the development of a simple example, this chapter gives all the details necessary to appreciate the essentials of programming. All programs are simply a list of instructions that the computer will follow mindlessly. The instruction list may be reduced in length by making repeated segments into a single instance of a subprogram which can be re-executed any number of times. Other repeated instruction segments may be included in a loop structure that directs the computer to repeatedly execute the instructions included within it. Use of a loop structure introduces a branch point where the execution sequence may either go around the loop or not. This list of instructions, the program, then determines a complex flow structure (as the collection of all potential flow paths), but makes no effort to expose it. It is the flow structure (in conjunction with branch conditions and specific storage-box values) that directly determines the program behaviour that emerges. Stepwise refinement from program plan to programming language instructions is introduced and contrasted with ad hoc concoction of programs. Some program style guidelines (just COMMENTs and indentation as a layout feature) are introduced as an aid to human comprehension. Subprograms and loops reduce program size but increase flow structure complexity. Consequently, the programmer attempting to eliminate an error, or otherwise modify the emergent behaviour, can only work by rearranging the list of instructions but must think in terms of the flow structure repercussions.
Derek Partridge
Chapter 5. Recipes for What?
Abstract
Programming demands mastery, on a massive scale, of fine grained complexity springing from a network of constraints: some logical, some stylistic and some an ill-defined combination. Principles of program style and structured programming – such as, modularity, encapsulation, and localization of scope – minimize complexity and so facilitate program understanding through flow-structure visualization. Principles of program style, naturally developed through stepwise refinement, are made manifest through layout conventions, and can significantly facilitate understanding of the all-important flow structure. Poor, incomplete and outdated stylistic aids, a natural consequence of the Happy Hacker Syndrome, can seriously misdirect program understanding. IT-system documentation, such as design diagrams and notes, can similarly assist program understanding, or misdirect it. Programming in the small is totally different from large IT system development – size really does matter. Whiz-kid hackers are the worst IT-system developers. IT-system maintenance is first introduced as a further aggravation in our quest for high-quality IT systems. A lot of IT-system maintenance is debugging, i.e., finding and fixing errors.
Derek Partridge
Chapter 6. Programs: The Good, the Bad, and the Verified
Abstract
An IT-system specification is a complete, precise and unambiguous statement of what the desired IT system should do. A correct IT system is one whose behaviour is exactly as specified. Testing can never deliver a guarantee of IT-system correctness. Programs are, however, well-defined symbol structures just like mathematical formulae, and thus hold the promise of being proven correct. Mathematical proof, the time-honoured mechanism for demonstrating the correctness of well-defined symbol structures, has its strengths and weaknesses especially in relation to IT systems. IT systems, by virtue of sheer complexity, have significantly muddied even this neat mathematical idea. Both proofs and specifications of IT systems will be large and complicated ‘objects’ just like the programs. There are some fundamental problems with IT system specification, and a major source of difficulty is explained in the next chapter.
Derek Partridge
Chapter 7. Going to Ground with Symbols
Abstract
Grounding is an interpretation of a symbol structure in terms of some real-world phenomena. If an IT system is to be used to impact on the real world, the symbol structures of the program, just like those in mathematical formulae, must be interpreted in terms of real-world phenomena – parts of the program must be grounded. Grounding is not rule-governed, it is a matter of choice and so shatters certainty of abstract behaviour. Formal verification of programs (or parts of programs) is a potentially useful tool for grappling with IT-system correctness, but it can never be a complete answer.
Derek Partridge
Chapter 8. Hooptedoodle 1 – The Proof of the Science is in the Pudding
Abstract
In this diversionary chapter we explore and expose the common misconception that scientists prove things to be true. We look at some historical examples of rejected ‘truths’ as well as more modern scientific confrontations such as the cold fusion sage. We expose the mismatch between commonsense and logical thinking, and briefly touch on the latest focus of concern – global warming.
Derek Partridge
Chapter 9. The Soft Machine
Abstract
There is no valid reason to limit the notion of a machine to hard ­components. A computer program is a machine, a soft machine. An IT system is composed of a hard machine (usually electronic components) and a soft machine, a computer program. In principle, the relative mix of hard and soft components in an IT system is entirely arbitrary. In practice, IT systems are primarily soft machines. The soft machine becomes grounded within the hard components of an IT system (the computer hardware), and the IT system as a whole is then grounded by the context in which it is used, and its inputs and outputs are interpreted. Even this initial grounding, which cannot be avoided for a soft machine, wrecks the scope for formal proofs of IT system correctness.
Derek Partridge
Chapter 10. Computers Only Do as They’re Told
Abstract
What we’ve told a computer to do must be distinguished from what we believe we’ve told it to do. Knowing what you’ve told a computer to do is impossible to establish with certainty. A program module has only one flow-path in and one flow-path out. Well-structured (i.e. modular) IT systems can be contrasted with spaghetti-code systems, and the former considerably assist the task of knowing what you’ve told the computer to do. Modern IT system design and development still suffers from the puzzle solving-and-setting practices that were important in the early days of programming, such as the one liner. This remains a detrimental element of the allure of programming.
Derek Partridge
Chapter 11. Hooptedoodle 2: Recursing Through Tescos
Abstract
In this diversionary chapter we examine the powerful computational notion of recursion – defining something in terms of itself, which is not necessarily viciously circular. Recursive procedures can be logically simple and straightforward and, at the same time, mechanically very complex. We conclude with examples of English sentences that are grammatically acceptable yet impossible to understand because they require recursive processing, apparently. The conclusion is that the human brain is not equipped for recursive processing.
Derek Partridge

The Way of the Seducer

Frontmatter
Chapter 12. Intimate Relationships of the Computational Kind
Abstract
Male-female close relationships are not symmetrical. The tireless, non-judgemental and (apparently) endless novel responses of a computer supply the interdependence required for a stable close relationship. An entity capable of endless and inexhaustible giving may be more attractive to males than females. For a sustained relationship, the creative genius needs interaction with the ever-ready and lightning-fast machine – but why primarily males? Males (more than females) tend to perceive, and resent, under-benefit in a relationship; this never happens when the partner is a computer. The intimacy, based on total guaranteed privacy, can be expected to encourage a close relationship – all faults are accepted without rebuke. The non-competitive computer never challenges self-image – another primarily male weakness when developing a close relationship. The happy hacker has found a partner that: 1. Understands him 2. Values his talent 3. Cares for him 4. Needs to be cared for (perhaps led rather than mothered) What more could a man want? Or a woman? But perhaps she too readily sees through this perception whereas a socially isolated male does not? Perhaps it’s a male-male bond not a male-female one; the drive is to scale new heights with his amazing partner, not to isolate themselves in a bond of mutual admiration?
Derek Partridge
Chapter 13. Programming with Flair
Abstract
The compulsive nature of programming has long been recognized. It is not, however, the addicts that are the problem; it is the less extreme manifestations in virtually all programmers that undermine proper IT system design and development. The majority of these afflicted persons are not building IT systems from scratch; they are maintaining existent systems – a distinction that severely aggravates all the existing difficulties. Effective maintenance is based on program understanding and this is facilitated by well-structured systems, and support from software tools, such as editors. One of the reasons for the prevalence of maintenance is that IT systems represent too big a commitment to organizational infrastructure to abandon, so they are maintained well beyond their proper life span. These long-used IT systems, termed legacy systems, introduce further difficulties, such as (apparently) dead code. Even with a large IT system to be constructed from scratch, the model programmer will eventually be drawn into grappling with an unmanageable system. The essential difference between the happy hacker and the sober and well-disciplined programmer is the speed with which an IT system becomes unmanageable, and the extent of the chaos generated (which is often manifest in an excessive need for testing and debugging).
Derek Partridge
Chapter 14. Hooptedoodle 3: The Seductive Gene
Abstract
Sequencing DNA (and hence genes) is a hot topic. Weekly we get media reports of a new sequence and associated promises of breakthroughs just as soon as this sequence is understood in terms of the behaviour it controls – e.g. the genetic basis of certain cancers. Gene (or DNA) understanding is similar to the central problem of this book, i.e., program understanding, and we now know how difficult (more accurately, impossible) that is. The main difference is that gene understanding will be far more difficult in every way. We look at the similarities between these two ‘understanding’ tasks, and conclude pessimistically for the future of gene understanding. This conclusion does, however, also has an optimistic angle.
Derek Partridge
Chapter 15. Runaway Programs: Dr Frankenstein’s Predicament
Abstract
During long-term use every IT system needs to be maintained by making changes that will inexorably undermine good structure and so reduce understanding; in this sense they will always runaway. In general, IT systems defy human comprehension because: 1. Full understanding demands mastery of an excessive span of detail 2. Small misunderstandings can have large repercussions IT systems pose wholly new challenges to human understanding because they are complex discrete systems, quite unlike both natural systems and other engineered complex systems. The discreteness of IT systems is manifest in several ways; it is primarily the single-threaded decision-logic basis of IT systems that is the root problem. Small, “nicely-factored” discrete systems are readily amenable to formal analysis (possibly even proof of correctness); large discrete systems with tight internal couplings (such as most IT systems) are not. Small, “nicely-factored” systems are also readily comprehensible; large ones (made even larger by the avoidance of the succinct power of inter-couplings) are not – they present as a conglomerate of individual components, which, of course, they are if all inter-couplings are eliminated. Complex natural systems achieve stability through redundancy, and predictability through monotonic analogue (rather than discrete) basics. ‘System science’ has failed to encompass systems of discrete complexity. The mathematical basis from which much of programming practice has been developed has severely undervalued redundancy as a system feature. Discrete systems tend to be unpredictable – hence the extreme weakness of IT-system testing as a validation procedure.
Derek Partridge
Chapter 16. Sneakaway Programs: Everybody’s Predicament
Abstract
In-use IT system confidence becomes suspect every time an IT system is exposed to potential change-access. The elements of IT-system access control are introduced and discussed. Inadvertent change, due to clumsiness, or covert malicious change causes IT systems to sneakaway. All IT systems must be open to change; usually managed through passwords. Bio-metric access control, such as fingerprint matching, is a growing alternative to passwords. These avoid the memorisation task of many passwords but: successful duplication or simulation will open all doors (whereas use of multiple passwords can protect against this); we lose the convenience of giving (perhaps temporary) access to someone else; and matching to approve access becomes complicated (and thus error prone). Beyond the privacy concerns of read-only access, access to change IT systems must be closely controlled and monitored. This control is it odds with ease of access for essential system changes, e.g. just adding new information, or making corrections. Change-access control for an IT system may be a complex, multi-level procedure, i.e., different users require access to different system-modification possibilities. Further complication to the ever-present threat of malicious system access and modification is introduced through the convenience of computer networking, such as made possible by the Internet.
Derek Partridge
Chapter 17. Hooptedoodle 4: Bases for Data Security
Abstract
This diversionary chapter examines the essential tension between keeping database information secure and keeping it up to date. It refutes the excuse for lost data that the proper procedures were not followed. The procedures should be encoded in an IT system, and then there is no choice but to follow them. In addition, automatic audit trails and can record all database activity including the explicit authorizations given for the each activity.
Derek Partridge
Chapter 18. The Roles of Software in Society
Abstract
IT systems have a life-cycle in which maintenance is the dominant activity. Maintaining (i.e. extending and debugging) an IT system that you did not develop exacerbates all of the IT-system problems, and is the major programming effort. At a certain point in IT-system complexity, further debugging is a self-defeating exercise. We all live within a mesh of IT systems: some offer conveniences that we can either accept or reject, others do not give us a choice. The outputs of an IT system may be viewed as a useful guide to be accepted cautiously, or as the ultimate truth to be accepted blindly; the reality of all IT systems will lie somewhere in between these two extremes. IT systems are not extended or amended lightly, because change is so dangerous; hence, we tend to ‘work around’ their failings. Many IT systems improve our lives. Some IT systems have negative impacts, all the way from minor aggravation to life threatening. There are no easy answers (as far as we know). So for IT systems in safety-critical roles where failures have the potential to cause deaths and/or disasters, the best advice is too lessen the criticality of their roles and to limit expectation of what they can deliver.
Derek Partridge

Pieces of Resistance

Frontmatter
Chapter 19. Help from Within
Abstract
A general mechanism for self-explanation was a spin-off of Expert Systems Technology (EST) which attempted to mechanise human expertise using IT systems composed of a knowledge base (a database of rules and facts) and an inference engine (that deduces further information from user input and the knowledge base). It is persuasive in the small, but fails in the large. Just as with programs, the clarity of small context-free elements (program instructions or IF-THEN rules) is quickly lost when the system, or the purported explanation of the system, grows to be a large collection of these elements. The simplest explanation of a complex system may be complex (although hopefully less complex). Comprehensibility of complex explanations is probably best achieved (insofar as it can be achieved at all) through a combination of sophisticated structure and simple elements; it cannot be achieved through an unstructured mass of simple elements. A putative solution that is programmed, like self-explanation, is subject to all the same difficulties as the IT system it claims to explain.
Derek Partridge
Chapter 20. A Moderately Stupid Assistant
Abstract
IT-system development complexity can be lessened by the use of other programs that monitor the programming and provide information about program structure to the programmer. An integrated suite of such helpful programs is a programming support environmen t. Simple, factual support is easily provided. More sophisticated support quickly extends into AI research areas, and is not easily provided. Accurate simple support is preferable to sophisticated support of dubious quality. Moderately stupid assistance’ is the level of help to expect. Automated support may be either pro-active or on-demand only, or some combination. Constant interruptions with worthless, or erroneous, ‘help’ are worse than no help at all.
Derek Partridge
Chapter 21. Watching Programs Work
Abstract
IT systems are fundamentally dynamic objects, yet we try to understand them via static representations. Computer systems are quite capable of generating dynamic representations of ongoing computations. Every IT system executes in the context of an operating system which can execute other programs at the same time. The power of the human visual system can be exploited to aid IT system understanding via dynamic system-visualization techniques. The related idea of visual programming is also introduced.
Derek Partridge
Chapter 22. Classical Reconditioning: Doing What Happens Naturally
Abstract
The organic world is full of stable, reliable complex systems. IT systems’ technologists may therefore find some useful structures and processes in the world of biology. Evolution, crudely viewed as a process involving time, random changes and selection, has found application in complex optimization. Neural computing (originally inspired by the impressive computational properties of brains) has been developed in a number different ways. Network programs, hence network programming, appear to circumvent some fundamental weaknesses of conventional programs. But network programming has its own weaknesses and cannot, as yet, be used for large-scale, multifunctional IT systems, although network programs could be elements of such systems. Network programming may offer the software engineer a new paradigm and so require fundamental shifts in thinking about applications and management of computational technology
Derek Partridge
Chapter 23. A Computer That Knows When It’s Wrong
Abstract
Useful IT systems may operate in domains in which results are fundamentally equivocal, and this is at odds with the correct-or-incorrect basis of computing technology. In reality, all IT system results are to some degree equivocal, and, instead of retrofitting conventional discrete technology to accommodate this feature, we might compute in terms of well-founded continua – precise approximation computation (PAC). An IT system with PAC-based components can determine (from the manner in which the computation proceeds) whether a computed result is suspect or not, and valuable use could be made of this ‘knowledge’. PAC, in several manifestations, appears to offer the possibility of providing the necessary ‘self-knowledge’. Like neural-computing technology, the precise approximations technologies are currently limited in scope and would apply to specialist components of IT systems rather to IT systems as a whole. The move to continuous probability distributions or spaces does circumvent some of the problems associated with discrete computation, but it also introduces issues of discrete interpretation, or summaries, of the continuities computed. Although the precise approximation strategies illustrated are based on sound statistical principles, fundamental assumptions are involved, and these need to be thoroughly researched before full weight can put on the probabilistic continua computed.
Derek Partridge

The End of the Affair

Frontmatter
Chapter 24. Analysis and Counselling
Abstract
This chapter lists the main elements of my argument, each associated with a pointer to where exactly it is justified in the preceding chapters. As a sequence of bullet point summaries, one associated with each of the preceding chapters, it provides an alternative entry point to the book as a whole. It concludes with a super-summary.
Derek Partridge
Chapter 25. The Epilogic
Abstract
In this short, final chapter a number of summary slogans are developed: Large IT systems must be grown, not built. IT-system behaviour is an emergent phenomenon. A variety of characteristics conspire to produce inevitable unmanageability; 12 such negative features of the basic technology are listed. Small-scale examples are a poor guide to large-scale consequences. IT-system technology is well-defined in principle, but ill-defined in practice. From development to maintenance IT system personnel are grappling with incipient chaos. The technicians are seduced by the detailed challenge of the technology. The scientists are seduced by the promises of their technology. The managers and users are seduced by the mysteries of the technology. No IT system is fully understood, so surprising behaviours will always emerge.
Derek Partridge
Backmatter
Metadata
Title
The Seductive Computer
Author
Derek Partridge
Copyright Year
2011
Publisher
Springer London
Electronic ISBN
978-1-84996-498-2
Print ISBN
978-1-84996-497-5
DOI
https://doi.org/10.1007/978-1-84996-498-2

Premium Partner

    Image Credits