Facts and Fallacies of Software Engineering (Paperback)

But my specific interest revolves around writing software in large engineering (hard engineering) companies, in that very peculiar environment. Specifically, the hard engineering environment in which knowledge of the programming language is considered the most advanced software theory needed to produce a product, and in which Electrical Engineers without any formal education in advanced data structures, algorithms to manipulate them, search strategies, and heuristics are writing most of the code.

I am seeing HUGE software projects fall FAR short of their schedulled goals, because those doing the coding have simply used up all their computational cycles (I'm talking about real-time software). In these situations, managers seem to imply
1. they were blindsided
2. there are no ways to forsee such computational box canyons
3. no one could have done better, anyway.

On all 3 points, managers are wrong. And the substance on which they are so badly wrong, would make for another 10 fallacies in Glass' book. For example:

Fallacy N: Hard engineers produce advanced software algorithms.
The average hard engineer is writing Freshman undergraduate code, and making basic errors in design.

Fallacy N+1: Simple code (meaning no Computer Science theory) is much more efficient than highly tailored software algorithms. Actually, it is often orders of magnitude less efficient.

Fallacy N+2: Analytical mathematical solutions are the only ones worthy of respect. Actually, with the incredibly complex problems in modern engineering, closed form mathematical solns may never be found. Many such solns are so computationally expensive, that they never could be practical solutions.

Fallacy N+3: There are no analytical methods for identifying algorithms with prohibitive computational complexity--you must just write the software and try it out. Actually, there is a whole field of C.S. that does this.

Fallacy N+4: Modern Engineering problems are unique. Actually, the tar pits of computational complexity remain pretty stable, and Artificial Intelligence has amply failed in most of them (such as the Frame problem, and Automated Reasoning). Managers are just ignorant of the tar pits.

Fallacy N+5: Next year we'll get a new processor which is 60% faster, and our problems will go away. Actually, the mathheads that keep saying this have still not figured out that the disastrous software algorithms have computational growth rates that are exponential, and linear growth in processor speed does not define a solution to this problem.

Fallacy N+6: We write modular software. Actually, "modular" to a hard engineer and "modular" to a software engineer are radically different things. I regularly see "modular" software that has no defined interface, and no behavioral contract, so does not meet even basic requirements for reuse. Glass does not address the radically different semantics given the same words, by software and hard engineers. "Algorithm" is another word with very different meanings.

Fallacy N+7: Rule-Based software will, of course, solve our problem. Actually, automated reasoning has large undecidable and intractable areas. Engineering companies are just beginning to step in this tar pit, 25 years behind Artificial Intelligence.

Fallacy N+8: Knowledge of the syntax of a computer language, is the most valuable asset in software design. Actually, this is a trivial skill, relatively. The ability to represent symbolically complex reality in code structures, and complex manipulations of those structures efficiently, is orders of magnitude more valuable. Knowledge of just language syntax leads to literalistic algorithms, which tend to be brute force.

To his credit, Glass did mention...
Fallacy: Real-time code optimizers will fix any slowness in execution. Actually, you may gain 10-18% in speed this way, but these failing projects are orders of magnitude slower then needed. Better get rid of the real-time optimizers, and hire highly educated software designers.

I REALLY, REALLY appreciate Glass. But someone with a modern Masters degree in C.S. would realize that there is no reason to be blind-sided by most of these software disasters, and there are proven ways of evaluating these risks of failure while still in the design stage. Most VERY VERY bright hard engineers don't have the basic theory to detect computational risk, and don't even know where they should acquire it, if they wanted to improve their software algorithm design ability.

The problem is not just that (as Glass mentions) managers of software projects are out of touch with the technical people who write software. The disconnect is rather worse: most of the people who write software in big engineering companies are hard engineers, with no theoretical background in software algorithm design. There is an unspoken "amateur ethic" which condemns formal design theory. Technical leads of these "programmers" are often as uneducated, and could not identify sound software designs if their career depended on it. (So they are continually promoting Public Relations designs, and being blind-sided by failures.)

The situation in software design in America remains "tragic," and anti-intellectual, and the amateur (KISS) ethic continues to produce software projects which are computationally orders of magnitude outside of feasibility. Process does not begin to address this problem (Glass alludes to this). Nor does the strategy to redouble expectations toward the ï¿amateur coding ethicï¿ and stop being such a nay-sayer. The truth remains that most technical leads in engineering companies, cannot even recognize what a software design is, and have no theoretical tools to analyze computational feasibility.

I wish that someone would address this problem in basic "Facts and Fallacies" books.

Stephen Wuest, Raytheon, M.S. in C.S. and A.I., 1999.

This book will open your eyes. If you work in the field, you'll never think about your livelihood the same way again.

If you take only one thing away from this book, remember this: don't blindly trust what the advocates of the latest methodology are saying, whether it be OO, XP, RUP, or UML, without some substantive evaluative research backing them up. Glass makes compelling arguments as to why the software industry has fallen easy prey to the hucksters and snake-oil salesmen.