Chapter 1The Software BusinessTo run a business and be successful, there are some basic requirements. We must understand theprocesses and products of the business, i.e., we must know the business. We must define our businessneeds and the means of achieving them, i.e., we must define our product and process characteristics andqualities. We must evaluate every aspect of our business, so we can understand our successes and ourfailures and where to make changes. We must define closed loop processes to feed back informationfor project control and accumulate knowledge for corporate learning. We must learn from ourexperiences, i.e., each project should provide information that allows us to do business better the nexttime. We must build competencies in the domain of our business by packaging our successfulexperiences for reuse, and then we must make these successful experiences or business specificcompetencies part of our business.Thus, any successful business requires a combination of technical and managerial solutions. It requires awell defined set of product needs so we may articulate and satisfy our customers and assist thedeveloper in accomplishing this task, and create competencies for future business. It requires a welldefined set of processes to provide a means of accomplishing what needs to be accomplished,controlling the development, and improving the overall business. A successful business requires anynumber of closed loop processes that provide project feedback for control and real-time modificationof the project process, and support for organizational learning across multiple projects. Keytechnologies necessary for supporting these requirements include the modeling, measurement, and reuseof the various processes, products, and other forms of knowledge relevant to our business.But almost any business today involves the development or use of software. It is either the main aspectof the business, the value added to the product, or it is on the critical path to project success. Itpermeates every aspect of our lives. For example, a company like AT&T is not in the telephonybusiness but in the software telephony business. Its systems are not analog but digital and the functionprovided to the customer is predominantly software; although it may make its profit from sellinghardware in the form of switches, etc. A company like IBM is not just in the computer hardwarebusiness but in the computer software business. It provides its customers with an integrated softwaresystem of applications that communicate across various hardware platforms. Customers purchase theirsystems for the functions they deliver and these functions are mostly software intensive. If anorganization does not recognize that it is in the software business and is not treating software as abusiness, i.e., investing in building core competencies, then it is not evolving and improving as a business,will not be competitive and may not be in business in the future.But what is software? What is the nature of this artifact? What is the nature of the processes by which itis built? This book is based upon the view that software is developed, in the creative, intellectual sense,rather than produced in the manufacturing sense. The software processes are development notproduction. This aspect of the discipline is probably the most important in determining how we dobusiness. We have learned a great deal over the years about production processes. We have manymodels and techniques we can use to learn about the product and processes, feedback information,build models, measure effects, reuse knowledge, and improve production, based upon the works ofDemming, Juran, Ishikawa, etc. But there has been little support for development processes in the past.This may be in part because manufacturing has made its profits on the efficiency and quality of itsproduction rather than the efficiency of its development. Companies were willing to ôpay a little moreöfor development because they did not develop many products from scratch, were willing to pay for thebenefits of creativity, did not want to interfere with the creative juices, etc. However, software is alldevelopment, i.e., production is negligible, so we have to worry about improving the developmentbusiness.A second premise of this book is that the software discipline is evolutionary and experimental; i.e.,software engineering is a laboratory science. There is a relationship between the various processes weapply and the product characteristics that result and this relationship cannot only be understood byanalysis. We need to experiment and learn from our experiments whether such relationships hold, howthey vary, what the limits of various technologies are, so we can know how to configure porcess todevelop software better.A third premise is that the technologies of the discipline are predominantly human based. This means wewill never eliminate the thinking process. There are steps that can be automated but, the most importanttechnologies, such as design and reading, must always be done by people. This creates problems forour experiments because there will always be variation in the results based upon human differences.To compound the current problems, the discipline is immature in the sense that there is a lack of modelsthat allow us to reason about the process and the product. This compounds the non-visible nature ofsoftware. In most cases, we do not even have intuitive models of the software product. Consider theimplications of this statement. Suppose I asked you to build a car with a fifth wheel equidistant from theother four. You do not have to be an automotive engineer to know that this request is ridiculous.Because you have an intuitive model of the chassis of a car, you know that this extra wheel would addno useful function and it would be difficult to take an existing automobile design and make themodification. But if I asked you to add the functional equivalent of a fifth wheel to a software system,even if you were able to assess the benefits or lack thereof of the new function, it is not clear that youwould be able to understand the limits of the existing design relative to the requirements for themodification.Software is difficult. This statement is often not fully appreciated. It is difficult because it is the part of thesystem that is new, we least understand or requires the greatest amount of change. And there is agenuine lack of understanding of implications of change. The