Code Simplicity The Science of Software Development (Max Kanat-Alexander) (Z-Library)

📄 File Format: PDF

💾 File Size: 5.8 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

(This page has no text content)

📄 Page 3

Code Simplicity Max Kanat-Alexander Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo

📄 Page 4

Code Simplicity by Max Kanat-Alexander Copyright © 2012 Max Kanat-Alexander. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com. Editors: Andy Oram and Mike Hendrickson Production Editor: Melanie Yarbrough Copyeditor: Rachel Head Cover Designer: Karen Montgomery Interior Designer: David Futato Illustrator: Robert Romano Revision History for the First Edition: 2012-03-22 First release See http://oreilly.com/catalog/errata.csp?isbn=9781449313890 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Code Simplicity, the cover image of a ring dove, and related trade dress are trade- marks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein. ISBN: 978-1-449-31389-0 [LSI] 1332356930

📄 Page 5

Table of Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What’s Wrong with Computers? 1 What Is a Program, Really? 3 2. The Missing Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Every Programmer Is a Designer 6 The Science of Software Design 7 Why Has There Been No Science of Software Design? 9 3. The Driving Forces of Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 The Goals of Software Design 16 4. The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 The Equation of Software Design 19 Value 20 Effort 21 Maintenance 22 The Full Equation 23 Reducing the Equation 23 What You Do and Do Not Want 24 The Quality of Design 26 Unforeseeable Consequences 27 5. Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Change in a Real-World Program 31 The Three Flaws 34 Writing Code That Isn’t Needed 34 Not Making the Code Easy to Change 36 Being Too Generic 38 iii

📄 Page 6

Incremental Development and Design 40 6. Defects and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 If It Ain’t Broken... 44 Don’t Repeat Yourself 45 7. Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Simplicity and the Equation of Software Design 49 Simplicity Is Relative 49 How Simple Do You Have to Be? 51 Be Consistent 53 Readability 54 Naming Things 55 Comments 56 Simplicity Requires Design 56 8. Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Complexity and Purpose 61 Bad Technologies 62 Survival Potential 63 Interoperability 63 Attention to Quality 64 Other Reasons 64 Complexity and the Wrong Solution 64 What Problem Are You Trying to Solve? 65 Complex Problems 65 Handling Complexity 66 Making One Piece Simpler 68 Unfixable Complexity 68 Rewriting 69 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A. The Laws of Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 B. Facts, Laws, Rules, and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 iv | Table of Contents

📄 Page 7

Preface The difference between a bad programmer and a good programmer is understanding. That is, bad programmers don’t understand what they are doing, and good program- mers do. Believe it or not, it really is that simple. This book exists to help all programmers understand software development on a very broad level that can be applied to any programming language or project from here to eternity. It lays out scientific laws for software development, in a simple form that anybody can read. If you are a programmer, these laws will help explain why certain software development methods work and why some don’t. They will help guide you in making software de- velopment decisions on a day-to-day basis, and they will help your team have intelligent conversations that lead to sensible plans. If you aren’t a programmer but you work in the software industry, you may find this book useful for several reasons: • It is an excellent educational tool to use in the training of junior programmers, while still containing information that is highly relevant to senior programmers. • It will allow you to more effectively understand why software engineers want to do certain things, or why software should be developed in a certain way. • It can help you communicate your ideas effectively to software engineers, by help- ing you understand the fundamental principles on which good software engineers base their decisions. Ideally, everybody who works in the software industry should be able to read and understand this book, even if they don’t have a lot of programming experience, or even if English is not their native language. Having more technical understanding will help in grasping some of the concepts, but most require no programming experience what- soever to understand. In fact, even though this book is about software development, it contains almost no program code. How can that be? Well, the idea is that these principles should apply to any software project, in any programming language. You shouldn’t have to know some specific programming language just to understand things that apply to all v

📄 Page 8

programming, everywhere. Instead, real-world examples and analogies are used throughout the book to help you get a better understanding of each principle, as it is presented. Most of all, this book was written to help you, and to help bring sanity, order, and simplicity into the field of software development. I hope that you enjoy reading it and that it improves your life and your software in some way. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names. This icon signifies a tip, suggestion, or general note. This icon indicates a warning or caution. Attribution and Permissions This book is here to help you get your job done. If you reference limited parts of it in your work or writings, we appreciate, but do not require, attribution. An attribution usually indicates the title, author, publisher, and ISBN. For example: “Code Simplicity: The Science of Software Development by Max Kanat-Alexander (O’Reilly). Copyright 2012 Max Kanat-Alexander, 978-1-4493-1389-0.” If you feel your use of examples or quotations from this book falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. Safari® Books Online Safari Books Online (http://my.safaribooksonline.com) is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business. Technology professionals, software developers, web designers, and business and vi | Preface

📄 Page 9

creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training. Safari Books Online offers a range of product mixes and pricing programs for organi- zations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable da- tabase from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Tech- nology, and dozens more. For more information about Safari Books Online, please visit us online. How to Contact Us The author maintains a website at http://www.codesimplicity.com where you can make contributions and submit comments and corrections. Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at: http://www.oreilly.com/catalog/9781449313890 To comment or ask technical questions about this book, send email to: bookquestions@oreilly.com For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Preface | vii

📄 Page 10

Acknowledgments My editors, Andy Oram and Jolie Kanat, have been an invaluable resource. Andy’s feedback was both insightful and brilliant. Jolie’s insistence and support were ulti- mately what got this book published, and her extensive editing work on the early drafts was highly appreciated. My copyeditor, Rachel Head, has a remarkable talent for clarifying and improving everything. All the programmers that I’ve worked with and talked with in the open source com- munity also deserve thanks—particularly my fellow developers on the Bugzilla Project who helped me try out all the ideas in this book on a real, live software system over the course of many years. The comments and feedback I’ve received on my blog throughout the years have helped me shape the form and content of this book. Everyone who has participated there deserves thanks, even those who simply encouraged me or let me know they’d read an article. On a personal level, I am tremendously grateful to Jevon Milan, Cathy Weaver, and everybody who works with them. In a very real sense, they are responsible for my being able to write this book. And finally, my hat’s off to my friend Ron, without whom this book would not have even been possible. viii | Preface

📄 Page 11

CHAPTER 1 Introduction Computers have created a major societal change. The reason is that they enable us to do more work with fewer people. That’s the value of a computer—it can do a lot of work, really fast. That’s great. The problem is, computers break. They break all the time. If anything else in your house broke as frequently as your computer, you would return it. Most people in modern societies experience a computer crashing or misbehaving for them at least once a day. That’s not so great. What’s Wrong with Computers? Why do computers break so much? For software, there’s one reason, and one reason only: bad programming. Some people blame management and others blame customers, but investigation shows that the root of the problem is always the programming itself. But what do we mean by “bad programming”? That’s a very ambiguous term. And programmers are generally very intelligent, rational people—why would some of them do “bad” programming? Basically, it all revolves around complexity. A computer is probably the most complex device that we can make in a factory today. It does billions of calculations per second. It has hundreds of millions of tiny electronic parts that all must function correctly in order for it to work. A program written on a computer is equally as complex. For example, when it was written, Microsoft Windows 2000 was one of the largest programs ever created, at somewhere around 30 million lines of code. Writing that much code is something like writing a book of 200,000,000 words—over five times the size of the Encyclopedia Britannica. 1

📄 Page 12

The complexity of a program can be particularly confounding, because there isn’t any- thing to put your hands on. When it breaks, you can’t pick up something solid and look around inside it. It’s all abstract, and that can be really hard to deal with. In fact, the average computer program is so complex that no person could comprehend how all the code works in its entirety. The bigger programs get, the more this is the case. Thus, programming has to become the act of reducing complexity to simplicity. Other- wise, nobody could keep working on a program after it reached a certain level of com- plexity. The complex pieces of a program have to be organized in some simple way so that a programmer can work on it without having God-like mental abilities. That is the art and talent involved in programming—reducing complexity to simplicity. A “bad programmer” is just somebody who fails to reduce the complexity. Many times this happens because people believe that they are reducing the complexity of writing in the programming language (which is definitely a complexity all in itself) by writing code that “just works,” without thinking about reducing the complexity for other programmers. It’s sort of like this. Imagine an engineer who, in need of something to pound a nail into the ground with, invents a device involving pulleys, strings, and a large magnet. You’d probably think that was pretty ridiculous. Now imagine that somebody tells you, “I need some code that I can use in any program, anywhere, that will communicate between any two computers, using any medium imaginable.” That’s definitely harder to reduce to something simple. So, some pro- grammers (perhaps most programmers) in that situation will come up with a solution that involves the equivalent of strings and pulleys and a large magnet, that is only barely comprehensible to other people. They’re not irrational, and there’s nothing wrong with them. When faced with a really difficult task, they will do what they can in the short time they have. What they make will work, as far as they’re concerned. It will do what it’s supposed to do. That’s what their boss wants, and that’s what their customers seem to want, as well. But one way or another, they will have failed to reduce the complexity to simplicity. Then they will pass this device off to another programmer, and that programmer will add to the complexity by using it as part of her device. The more people who don’t act to reduce the complexity, the more incomprehensible the program becomes. As a program approaches infinite complexity, it becomes impossible to find all the problems with it. Jet planes cost millions or billions of dollars because they are close to this complex and were “debugged.” But most software only costs the customer about $50–$100. At that price, nobody’s going to have the time or resources necessary to shake out all of the problems from an infinitely complex system. 2 | Chapter 1: Introduction

📄 Page 13

So, a “good programmer” should do everything in his power to make what he writes as simple as possible to other programmers. A good programmer creates things that are easy to understand, so that it’s really easy to shake out all the bugs. Now, sometimes this idea of simplicity is misunderstood to mean that programs should not have a lot of code, or shouldn’t use advanced technologies. But that’s not true. Sometimes a lot of code actually leads to simplicity; it just means more writing and more reading, which is fine. You have to make sure that you have some short document explaining the big mass of code, but that’s all part of reducing complexity. Also, usually more advanced technologies lead to more simplicity, even though you have to learn about them first, which can be troublesome. Some people believe that writing in a simple way takes more time than quickly writing something that “does the job.” Actually, spending a little more time writing simple code turns out to be faster than writing lots of code quickly at the beginning and then spending a lot of time trying to understand it later. That’s a pretty big simplification of the issue, but programming-industry history has shown it to be the case. Many great programs have stagnated in their development over the years just because it took so long to add features to the complex beasts they had become. And that is why computers fail so often—because in most major programs out there, many of the programmers on the team failed to reduce the complexity of the parts they were writing. Yes, it’s difficult. But it’s nothing compared to the endless difficulty that users experience when they have to use complex, broken systems designed by pro- grammers who failed to simplify. What Is a Program, Really? The phrase “a computer program,” in the way that most people use it, has two very distinct definitions: 1. A sequence of instructions given to the computer 2. The actions taken by a computer as the result of being given instructions The first definition is what programmers see when they are writing a program. The second definition is what users see when they are using a program. The programmer tells the computer, “Display a pig on the screen.” That’s definition 1, some instructions. The computer pushes around a lot of electricity that causes a pig to appear on the screen. That’s definition 2, the actions taken by the computer. Both the programmer and the user here would say that they are working with “a computer program,” but their experience of it is very different. Programmers work with the words and symbols, while users see only the end result—the actions taken. Ultimately, a computer program is both of these things: the instructions the program- mer writes and the actions the computer takes. The whole purpose of writing the in- structions is to cause the actions to happen—without the actions, there would be no What Is a Program, Really? | 3

📄 Page 14

reason to write the instructions. It’s just like in life, when you write a shopping list. That is a set of instructions about what to buy at the store. If you just wrote the in- structions but never went to the store, that would be pretty pointless. The instructions need to cause something to happen. There is a significant difference between writing a shopping list for groceries and writing a computer program, however. If your grocery list is disorganized, that will only slightly slow down your shopping experience. But if your program code is disorganized, ach- ieving your goals can become a nightmarish maze of difficulty. Why is this? Well, gro- cery lists are short and simple, and you throw them away when you’re done with them. Computer programs are large and complex, and you often have to maintain them for years or decades. So, while there’s only so much difficulty a short, simple grocery list can cause you, no matter how disorganized it is, disorganized computer code can cause you a truly enormous amount of difficulty. Additionally, there is no other field in which a set of instructions and the result of those instructions are so closely linked as they are in the field of software development. In other fields, people write instructions and then hand them off to other people, often waiting a long time to see them carried out. For example, when a building architect designs a house, she writes a set of instructions—the blueprints. These must go through many different people over a very long time to become a physical building. The final building is the result of all those people’s interpretations of the architect’s instructions. On the other hand, when we write code, there is nobody between us and the computer. The result is exactly what the instructions said to do, without question. The quality of the end result is dependent entirely upon the quality of the machine, the quality of our ideas, and the quality of our code. Of these three factors, the quality of the code is the largest problem faced by software projects today. Because of this fact and all the other points mentioned above, most of this book is about improving code quality. We do touch on ideas and machines as well in a few places, but mostly the focus is on improving the structure and quality of the instructions you are giving to the machine. When we spend so much time talking about code, though, it is very easy to forget that we are doing so purely because we desire a better result. Nothing in this book forgives a poor result—the entire reason that we focus on improving code is because improving the code is the most important problem we must solve in order to improve the result. What we need most, then, is a science for improving the quality of code. 4 | Chapter 1: Introduction

📄 Page 15

CHAPTER 2 The Missing Science This book is mostly about something called “software design.” Perhaps you’ve heard this term before, and maybe you’ve even read some books about it. But let’s look at it freshly, with new, precise definitions. We know what software is. So what we really have to define is the word “design”: verb 1. To make a plan for a creation. Example: The engineer will design a bridge this month and build it next month. noun 1. A plan that has been made for a creation that hasn’t been built yet. Example: The engineer came up with a design for a bridge; he will build it next month. 2. The plan that an existing creation follows. Example: That bridge over there follows a good design. All of those definitions apply when we talk about software design: • When we are “designing software” (“design” as a verb), we are planning it out. There are lots of things to plan about software—the structure of the code, what technologies we’re going to use, etc. There are many technical decisions to make. Often, we just make these decisions in our minds, but sometimes we also write down our plans or draw some diagrams. • Once we’ve done this, the result is a “software design” (“design” as the first noun definition). This is the plan that we made. Once again, this might be a written document, but it could also just be a bunch of decisions that we’ve made that we are now holding in our minds. • Code that already exists also has “a design,” (“design” as the second noun defini- tion), which is the structure that it has or the plan that it seems to follow. Some code may seem to have no clear structure at all—that code has “no design,” mean- ing that there was no definite plan made by the original programmer. In between “no design” and “a design” there are also infinite shades of gray, such as “a partial 5

📄 Page 16

design,” “several conflicting designs in one piece of code,” “an almost-complete design,” etc. There can also be actively bad designs that are worse than no design. For example, imagine coming across some code that had been intentionally made disorganized or complex—that would be code with an actively bad design. The science of software design is a science for making plans and decisions about soft- ware. It helps people make decisions like: • What should the structure of our program code be? • Is it more important to focus on having a fast program or a program whose code is easy to read? • For our needs, which programming language should we use? Software design does not cover subjects like: • What should the structure of the company be? • When should we have team meetings? • What times of the day should programmers work? • How should we measure the performance of our programmers? Those aren’t decisions about your software, they’re decisions about you or your orga- nization. It’s certainly important to make those decisions properly—many software projects have failed because they had poor management. But that is not the focus of this book. This book is about how to make the correct technical decisions about your software. Anything that involves the architecture of your software system or the tech- nical decisions you make while creating the system falls under the category of “software design.” Every Programmer Is a Designer Every programmer working on a software project is involved in design. The lead de- veloper is in charge of designing the overall architecture of the entire program. The senior programmers are in charge of designing their own large areas. And the junior programmers are in charge of designing their parts of the program, even if they’re as simple as one part of one file. There is even a certain amount of design involved in writing a single line of code. Even when you are programming all by yourself, there is still a design process that goes on. Sometimes you make a decision immediately before your fingers hit the keyboard, and that’s the whole process. Sometimes you think about how you’re going to write the program when you’re in bed at night. 6 | Chapter 2: The Missing Science

📄 Page 17

Everybody who writes software is a designer. Every single person on a software team is responsible for making sure that their own code is well designed. Nobody who is writing code for a software project can ignore software design, at any level. However, this does not mean that design is a democracy. You must not design by com- mittee—the result will be an actively bad design. Instead, all developers should have the authority to make good design decisions in their own areas. If they make poor or mediocre decisions, these should be overridden by a senior developer or the lead pro- grammer, who should have veto power over the designers below them.1 But otherwise, responsibility for the design of code should rest with the people who are actually working on it. A designer should always be willing to listen to suggestions and feedback, because programmers are usually smart people who have good ideas. But after considering all the data, any given decision must be made by an individual, not by a group of people. The Science of Software Design Software design, as it is practiced in the world today, is not a science. What is a science? The dictionary definition is a bit complex, but basically, in order for a subject to be a science it has to pass certain tests: • A science must contain knowledge that has been collected. That is, it has to be composed of facts—not opinions—and these facts must have been put together somewhere (like in a book). • This knowledge must have some sort of organization. It has to be put into cate- gories, the various pieces have to be correctly related to each other in terms of importance, etc. • A science must contain general truths or basic laws. • A science must tell you how to do something in the physical universe. It must be somehow applicable in work or in life. • Usually, a science is discovered and proven through the scientific method, which involves observation of the physical universe, making a theory about how the uni- verse works, performing experiments to verify your theory, and showing that the same experiment works everywhere to demonstrate that the theory is a general truth and not just a coincidence or something that worked just for you. 1. If you are the one overriding a decision, attempt to educate the other programmer when you do it. Show how or why your decision is better than hers. If you do this, over time you will have to override that programmer less and less. Some programmers never learn, though—if after several months or years of such education a programmer continues to make numerous bad decisions, he should be removed from your team. However, most programmers are very clever people who pick things up rapidly, so this is rarely a concern. The Science of Software Design | 7

📄 Page 18

In the world of software, we have lots of knowledge; it’s been collected in books, and it has even been somewhat organized. However, out of all the pieces required to make a science, we are missing the most important part: clearly stated laws—unshakeable truths that will never fail us. Experienced software developers know what the right thing to do is, but why is that the right thing? What makes some decisions right and some decisions wrong? What are the fundamental laws of software design? This book is the record of their discovery. It lays out a set of definitions, facts, rules, and laws for software development, mostly focused on software design. What’s the difference between a fact, a rule, a definition, and a law? • Definitions tell you what something is and how you would use it. • Facts are just true statements about something. Any true piece of information is a fact. • Rules are statements that give you true advice, cover something specific, and help guide decisions, but do not necessarily help you predict what will happen in the future or figure out other truths. They usually tell you whether or not to take some action. • Laws are facts that will always be true, and that cover a broad area of knowledge. They help you figure out other important truths and allow you to predict what will happen in the future. Out of all of these, the laws are the most important. In this book, you will know that something is a law because the text will explicitly say so. If you aren’t sure what category some piece of information falls into, Appendix B lists every major piece of information in the book and labels it clearly as a law, a rule, a definition, or just a plain-old fact. When you read some of these definitions, laws, rules, or facts, you may say to yourself, “That was obvious, I already knew that.” That’s actually quite expected—if you’ve been around the world of software development for a long time, you’ve possibly run into some of these ideas before. However, when you have this reaction, ask yourself: • Did I know that particular piece of data was proveably true? • Did I know how important it was? • Could I have communicated it clearly to another person, so that he fully understood it? • Did I understand how it related to other data in the field of software development? If you can say “yes” to some of those questions when you would previously have said “no” or “maybe,” then you have gained a specific sort of understanding, and that un- derstanding is a huge part of what differentiates a science from a mere collection of ideas. 8 | Chapter 2: The Missing Science

📄 Page 19

Of course, this science may not be perfect yet. There is always something more to discover in the universe, more to know about any field. Sometimes there are even cor- rections to be made to basic laws when new data is discovered or new facts arise. But this is a starting point! It’s something that can be built on: a real set of observable laws and truths for building software. Even if parts of this book are someday proven wrong and a better science is developed, it is important that one fact remain clear: software design can be a science. It is not an eternal mystery, subject to the opinion of every programmer who comes along or every consultant who wants to make a few bucks selling her “new method” of software de- sign: There are laws, they can be known, and you can know them. They are eternal, unchanging, and fundamentally true, and they work. As to whether or not the laws in this book are the correct laws...well, there are hundreds of examples and experiments that could be cited to prove them, but in the end, you’ll have to decide for yourself. Test the laws. See if you can think of any general truths about software development that are broader, or more fundamental. And if you do come up with anything or find any problems with the laws, see http://www.codesim plicity.com/ for how to contact the author with your contributions or questions. Any further developments in this subject will benefit everybody, as long as those develop- ments really are true, fundamental laws or rules of software design. Why Has There Been No Science of Software Design? Perhaps you’d be interested to know why a science for software design didn’t exist before this book. After all, we’ve been writing software for decades and decades now. Well, it’s an interesting story. Here’s some background that may help you understand how we got so far along with computers without developing a science of software design. What we think of today as “computers” started out in the minds of mathematicians as purely abstract devices—thoughts about how to solve math problems using machines instead of the mind. These mathematicians are the people we would consider the founders of computer science, which is the mathematical study of information processing. It is not, as some people believe it to be, the study of computer programming. However, the earliest computers were built under the supervision of these computer scientists by highly skilled electronic engineers. They were run by highly trained oper- ators in tightly controlled environments. They were all custom-built by the organiza- tions that needed them (mostly governments, to aim missiles and crack codes), and there were only one or two copies of any given model. Why Has There Been No Science of Software Design? | 9

📄 Page 20

Then along came UNIVAC and the world’s first commercial computers. At this point, there were only so many advanced theoretical mathematicians in the world. When computers started becoming available to everybody, it clearly wasn’t possible to ship a mathematician along with each one. So although some organizations, such as the United States Census Bureau (one of the first recipients of a UNIVAC), almost certainly had some highly trained operators for their machinery, other organizations undoubt- edly got their machines and said, “Okay, Bill from Accounting, this is yours! Read the manual and have at it!” And there went Bill, diving into this complex machine and doing his best to make it work. Bill thereby became one of the first “working programmers.” He might have studied math in school, but he almost certainly didn’t study the sort of advanced theory needed to conceive and design the machine itself. Still, he could read the manual and under- stand it and, by trial and error, make the machine do what he wanted. Of course, the more commercial computers that were shipped, the more Bills and the fewer highly trained operators we had. The vast majority of programmers ended up just like Bill. And if there’s one thing that Bill had, it was job pressure. He had demands from management to “Get that task done now!” and was told, “We don’t care how it’s done, just do it!” He figured out how to make the thing work according to its manual, and it did work, even if it crashed every two hours. Eventually Bill got a whole team of programmers to work with him. He had to figure out how to design a system and split up the tasks between different people. The whole art of practical programming grew organically, more like college students teaching themselves to cook than like NASA engineers building the space shuttle. So at this stage, there’s a hodge-podge system of software development, and it’s all very complex and hard to manage, but everybody gets along somehow. Then along came The Mythical Man Month (Addison-Wesley), a book by Fred Brooks, who actually looked at the process of software development in a real project and pointed out some facts about it—most famously, that adding programmers to a late software project makes it later. He didn’t come up with a whole science, but he did make some good observations about programming and managing software development. After that came a flurry of software development methods: the Rational Unified Process, the Capability Maturity Model, Agile Software Development, and many others. None of these claimed to be a science—they were just ways of managing the complexity of software development. And that, basically, brings us up to where we are today: lots of methods, but no real science. In fact, there are two missing sciences: the science of software management and the science of software design. The science of software management would tell us how to divide up work between programmers, how to schedule releases, how to estimate the amount of time a job will 10 | Chapter 2: The Missing Science