The overall purpose of this book is to enlighten those who are truly interested in developing computer software at low cost. There may be occasion for businesses, federal agencies, and corporations for which bringing in a system on budget and on schedule may be necessary. This could be when a company is in financial trouble, and there is a will to survive, or perhaps for some other critical reason, such as the sponsor or client threatening to cancel the contract.
I have seen software companies start with outstanding technical people and, from an initial impression, very capable managers. Yet it turned out that the man- agers had no intention of completing the project they were funded to do. For a while, I didn’t understand this phenomenon completely; then I saw the salaries paid to the key managerial staff. It was then that I realized that they were getting rich, regardless of whether the product was delivered or not. It surprised me even more that there were other customers standing in line to pick up the pieces and continue funding the project. To these ‘‘entrepreneurs’’ it was monetary gain, not a reputation for doing a good job and making the customer happy, that was important. I’m not talking about large corporations who defraud investors, but small business undertakings that cost a customer only $100 to $200 million.
These people are like small-time gangsters in computer science, the ‘‘Bonnies and Clydes’’ of software, as opposed to the Al Capone gangs that cost in the bil- lions.
So, this book is not intended for everyone. I address this book only to those soft- ware professionals who are genuinely interested in lowering the cost of software development and who are interested in where we are headed in computer science.
I address this book especially to those who would like to earn an honest living, have
LOW-COST SOFTWARE DEVELOPMENT 31
the capacity to absorb what I’m talking about, and would like to enjoy their chosen professions building great computer software products.
As mentioned briefly in the prologue, there are three key functions,a priori, in the activity involving the building of software systems:
1. The visualization of the product and its architecture 2. The visualization of the organization required to build it
3. The visualization of the methodologies and techniques required to achieve a quality product within a given time and budget
All three of these functions are the subjects of cognitive philosophy. The third function runs in parallel to the first two, and that is the ability of the manager-archi- tect to visualize inferentially the required methodology for implementing the objective design from the subjective impression of the architecture and organiza- tion. All of the chapters in this book combine in the methodology; that is how these are used by the manager-architect and applied in the process of building the system.
The methodology and how it is used are based on experience gained in the U.S.
Army, NATO/SHAPE, at the Jet Propulsion Laboratory, and as a consultant to some great American corporations (many of which have by now fallen by the wayside due to poor, inept, and incompetent management). My methodology is heavily influenced by some 20 years of experience as an officer in the U.S. Army Airborne Infantry and Special Forces units, of which nearly three years were spent in combat in Vietnam. The military influence comes from my observations of how people per- ceive things and events, how they react to events, and the conclusions they draw as evidenced by their reactions. As a young man, nothing interested me more than watching myself and others deal with, react to, and solve problems under pressure and stress.
Life in the Army was to me the real laboratory of human behavior. It is one of the reasons that I picked only the most challenging, dangerous, and stressful occupations and assignments I could find, and why I spent so much time in combat. I wanted to find out what made me and other people tick, how they got their jobs done, how they thought, and how they paid attention to the orders I gave.
Getting a job done well and expertly was to me always equal to the accomplish- ment of the mission without needless loss of life and resources. Failing to get the job done well and expertly because of negligence, lack of ability or competence, or someone else’s negligence is something I can understand but not tolerate. To those managers who can’t get their projects delivered by the standards I refer to in this book (to wit, a quality product, on schedule, and on budget): Do yourselves a favor and look for another profession. Don’t be a manager. There is no dishonor in not being a manager; just go back to systems engineering, programming or testing, and be productive. There is no excuse in saying that this project or that is too compli- cated. A manager gets paid to manage and to deliver a product; the complexity is not an issue.
3.8 ‘‘ON BUDGET AND ON SCHEDULE’’
As you know by now, the mantra of this book is the maxim: a quality product on budget and on schedule. To those who are not interested in this theme, don’t read this book, as it won’t do you any good; it will confuse you, and confusion leads to discomfort, and will only make you angry. But to those who think that being a soft- ware professional entails a love of one’s work, pride in one’s product, and having a happy customer who enjoys your product, this is for you. It is not intended to be a piecemeal, spoon-feeding approach to developing software with instant ‘‘solutions’’
to problems; there are many excellent textbooks dealing with such subjects. Rather, this is a summary in narrative form of experiences encountered over the course of a successful career building large systems from a hundred thousand to a million lines of code. This book should be a ‘‘beginning’’ for many of you to start you thinking about software in general, and about management, architectures, processes, and procedures in particular. It is not so much a roadmap as it is a checklist of important items that need to be considered when entrusted with a project. Granted, Kant’sCri- tique of Pure Reasonis not easy reading for most people,8but if you do read it, it will be of enormous help in getting the job done. It has been of great help to me.
The problem a software manager faces is more complex than that of a mechan- ical engineering project manager because there are no real blueprints in software design (at least, not yet). To get a project manager not familiar with computer soft- ware to understand that the articulation of the design in the detailed design docu- ment is our equivalent to a blueprint or mechanical drawing for a spacecraft bus is difficult.Yet without the software the aircraft or spacecraft will not work, much like without the nervous system the human body cannot function. These are simple ana- logies, but important ones. The Romans had a saying, ‘‘qui bene distingui, qui bene docet,’’ or ‘‘he who distinguishes well, teaches well.’’ Use analogies in your daily work so others who are working on the project understand what you are trying to get at. The most misunderstood part of management and systems engineering is that a good software manager and systems engineer or architect is always a good tea- cher. Manager-architects ‘‘teach’’ their teams what they want done, how they want it done, and explain why. They listen attentively to feedback from the individuals who need to get their jobs done, like a football coach listening to a quarterback, running back, or tackle about his views on the execution of a play. Infinite patience, direction, and communication coupled to experience, intelligence, and expertise in the field are the hallmarks of a true manager-architect.
8In the copy of Kant’sThree Critiquesthat I use (which is in high German for easy reading and annotated for better understanding), there is a statement by the interpreter-translator, Prof. Raymund Schmidt: ‘‘. . . wegen der sprachliche Unzugaenglichkeit der Kantische Schriften und wegen der historischer bedingt seiner Gedankenfuehrung dem Laien nicht ohne weiteres zutgemutet warden. . ..’’ This translates as: ‘‘. . . because of the linguistic inaccessibility of Kant’s writings, and because of his historically determined and constrained thought process, its understanding will not be easy for the layman.’’ Don’t be discouraged. All this means is that the original text of his work is written in old German, and his readability is very cumbersome. Read the annotated version I use: Kant,Die Drei Kritiken, Eine Kommentierte Auswahl.
Alfred Kroener Verlag, Stuttgart, Germany.
‘‘ON BUDGET AND ON SCHEDULE’’ 33
As with everything I have done in my career, I have always wanted to improve things in whatever I was working on. One of the things I strived for was the reduc- tion of cost. Why cost? As a very young Special Forces operative I had to parachute with and carry everything I needed on my back. If I could reduce the number of explosives I needed to destroy a certain type of target, I had less to carry. This car- ried over into every part of my professional career, software engineering included. I constantly searched for ways to reduce the overall cost of my systems, and this translated into cost per line of code (as a practical measure of performance), code complexity, and faults per line of code.