This chapter is from the book
This chapter is from the book
This chapter is from the book
The Primary Message
This book is about engineering economy, it's about aligning software technical decisions with the business goals of the organization. Many software professionals not only don't know how to look at the business aspects of their technical decisions, they don't even know that it's important to do so. Decisions such as "Should we use eXtreme Programming or should we use the Rational Unified Process on this project?" may be easy from a purely technical perspective, but those decisions can have serious implications on the business viability of the software project and the resulting software product. From my own experience teaching object-oriented development, I've asked more than 1,500 students why they were learning object-orientation. Reasons such as "It will help me develop higher quality software, quicker" or "It will be good for the company's bottom line" were extremely rare—fewer than 100 students total ever gave this kind of answer. The vast majority of the students answered, essentially, "It'll look good on my resumé."
In another case I was developing software to monitor radiation at nuclear power plants. Part of that software needed a sorting routine. I wrote a simple insertion sort routine and had that part of the system running in a matter of hours. A coworker insisted on developing a QuickSort routine because "everybody knows that QuickSort is better than insertion sort." At that time (early 1980s) reusable QuickSort routines weren't available; if you wanted one, you had to write it yourself. Unfortunately, QuickSort is a recursive algorithm, and the programming language we were using, Fortran-IV, didn't support recursion. My coworker spent more than a week developing QuickSort in Fortran-IV. Only later did he realize that the list that needed sorting averaged only about 30 entries and was predominantly sorted to begin with. Small lists that are already mostly sorted cause QuickSort to have extremely poor performance, typically worse than simpler algorithms such as insertion sort. Moreover, sorting happened in this system fewer than 50 times a day. Even if QuickSort did perform better than insertion sort, it would take decades for the company to recover its investment. My coworker's effort turned out to be a pretty big waste of the company's money and time.
The object-orientation and QuickSort examples are just two simple examples. Over the years I've seen technical decisions be inconsistent with the organization's business goals far more often than I've seen them be consistent. The software industry is hardly unique, however. This isn't the only time in history when the business impact of technical decisions was questionable. Eugene Grant [Grant90] wrote the following, referring to Arthur Wellington (a pioneer in the field of engineering economy).
Railway location obviously is a field in which many alternatives are likely to be available. Nevertheless, Wellington observed what seemed to him to be an almost complete disregard by many locating engineers of the influence of their decisions on the prospective costs and revenues of the railways. In his first edition (1877) he said of railway location, "And yet there is no field of professional labor in which a limited amount of modest incompetency at $150 per month can set so many picks and shovels and locomotives at work to no purpose whatsoever."
The average salary of software professionals today is well over $150 per month, but are our decisions really that much better than the railway-locating engineers' of the late 1800s? As software professionals, we had better be concerned with the impacts of our technical decisions on our employer—I'd say that Wellington's "a limited amount of modest incompetency" describes the contemporary software industry quite well.
This book bridges the gap between software technical decisions and business goals. The concepts and techniques in this book will allow you—the practicing software professional—to align your technical decisions with the business goals of your organization. This will help you waste less of your employer's limited time and money. The fundamental question that software professionals should always ask is, "Is it in the best interest of the organization to invest its limited resources in this technical endeavor, or would the same investment produce a higher return elsewhere?"