The Fallacy of Perfect Execution

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 4: Line 4:
''Fredericksburg, Virginia, USA''
''Fredericksburg, Virginia, USA''
-
Don't be embarrassed if you think you can create flawless code if you work hard enough. Many others have thought so, too. Unfortunately, it is not possible, even in theory.
+
Don't be embarrassed if youIf you think you can create flawless code if you work hard enough, don’t be embarrassed. Many others have thought so, too. Unfortunately, it is not possible, even in theory.
Arbitrary logic is hard to verify in the general case and hard, or impossible, to fully test. Drawing an analogy to the bricks and beams used in other construction-related activities, three researchers in the U.K. recently suggested that software is hard to verify because “there are no good, predictable building blocks. The elements out of which programs are constructed: statements, procedures, or objects, cannot be composed in a predictable fashion”.
Arbitrary logic is hard to verify in the general case and hard, or impossible, to fully test. Drawing an analogy to the bricks and beams used in other construction-related activities, three researchers in the U.K. recently suggested that software is hard to verify because “there are no good, predictable building blocks. The elements out of which programs are constructed: statements, procedures, or objects, cannot be composed in a predictable fashion”.
-
So, the building blocks of software don't snap together like Legos and they can be put together in so many ways that it is impossible to determine how many ways they can combine. That may be a decent working definition of Turing completeness*. Software is, in a word, complicated.
+
So, the building blocks of software don't snap together like Legos; and they can be put together in so many ways that it is impossible to determine how many ways they can combineall of the combinations. That may be a decent working definition of Turing completeness*. Software is, in a word, complicated.
Tracing and verifying arbitrary logic in code may sound esoteric. How about the simpler job of tracing programmer intent? Surely we can talk to programmers and ask them what they meant. Unfortunately again, programmer intent is generally lost within a few days of writing a code block, especially when requirements change or are inconsistently documented.
Tracing and verifying arbitrary logic in code may sound esoteric. How about the simpler job of tracing programmer intent? Surely we can talk to programmers and ask them what they meant. Unfortunately again, programmer intent is generally lost within a few days of writing a code block, especially when requirements change or are inconsistently documented.
Line 25: Line 25:
*Turing completeness - Named after Alan Turing, this is a concept that every design for a computing device could be emulated by a universal machine. True Turing-complete machines are physically impossible, due the the unlimited storage they would require. However, Turning completeness may be attributed to machines that would be universal ''if'' they had unlimited storage.
*Turing completeness - Named after Alan Turing, this is a concept that every design for a computing device could be emulated by a universal machine. True Turing-complete machines are physically impossible, due the the unlimited storage they would require. However, Turning completeness may be attributed to machines that would be universal ''if'' they had unlimited storage.
 +
 +
[RMH: Some minor changes made. See [http://www.monson-haefel.com/97things/projectmanagement/The_Fallacy_Of_Perfect_Execution.docx MS Doc] for changes]

Revision as of 12:27, 11 May 2009

The Fallacy Of Perfect Execution

David Wood Fredericksburg, Virginia, USA

Don't be embarrassed if youIf you think you can create flawless code if you work hard enough, don’t be embarrassed. Many others have thought so, too. Unfortunately, it is not possible, even in theory.

Arbitrary logic is hard to verify in the general case and hard, or impossible, to fully test. Drawing an analogy to the bricks and beams used in other construction-related activities, three researchers in the U.K. recently suggested that software is hard to verify because “there are no good, predictable building blocks. The elements out of which programs are constructed: statements, procedures, or objects, cannot be composed in a predictable fashion”.

So, the building blocks of software don't snap together like Legos; and they can be put together in so many ways that it is impossible to determine how many ways they can combineall of the combinations. That may be a decent working definition of Turing completeness*. Software is, in a word, complicated.

Tracing and verifying arbitrary logic in code may sound esoteric. How about the simpler job of tracing programmer intent? Surely we can talk to programmers and ask them what they meant. Unfortunately again, programmer intent is generally lost within a few days of writing a code block, especially when requirements change or are inconsistently documented.

Programmers also change jobs, leaving undocumented or wrongly-documented code behind. Source code rapidly becomes the last and only forensic clue to programmer intent. Alas, intent can only be imperfectly ascertained from clues like variable names, logic flow, and the occasional comment.

Bugs will remain part of every software product shipped. We put bugs into software for both bad reasons (like ignorance of language features or poor attention to detail) and good ones (such as conflicting or poorly communicated requirements). Further, bugs are a source of change in software because when they are recognized we refactor the code to fix them, meanwhile injecting new bugs in the process.

Meir (Manny) Lehman was the first to recognize that software evolves during its lifecycle, way back in 1969. He later figured out that multiple feedback loops exist within a software development effort, and that those feedback loops influence the process of evolution. Those feedback loops include the injection of multiple (possibly conflicting) requirements and design decisions.

Various degrees of programmer understanding of requirements, design decisions and implementation details contribute to other feedback loops. In other words, the sources of bugs don't have to be logical programming errors. Bugs are also introduced by differences of opinion.

The Fallacy Of Perfect Execution is the delusion that it is possible to create flawless code with sufficient attention to detail. If that were so, we would all be strong advocates of structured programming techniques. We aren't, and for good reason. Software, at any stage of its evolution, is buggy, extremely likely to change, and inaccurately documented.

That insight, simple though it may be, encourages us to approach software differently. It encourages us to develop tools and techniques to incrementally refactor software implementations, requirements, and documentation.

  • Turing completeness - Named after Alan Turing, this is a concept that every design for a computing device could be emulated by a universal machine. True Turing-complete machines are physically impossible, due the the unlimited storage they would require. However, Turning completeness may be attributed to machines that would be universal if they had unlimited storage.

[RMH: Some minor changes made. See MS Doc for changes]

Personal tools