Bugs most commonly come from somebody’s failure to reduce complexity. Less commonly, they come from the programmer’s misunderstanding of something that was actually simple. Other than typos, I’m pretty sure that those two things are the source of all bugs, though I haven’t yet done extensive research to prove it. When something is complex, it’s … Continue reading
Okay, most programmers know the story—way back when, somebody found an actual insect inside a computer that was causing a problem. (Actually, apparently engineers have been calling problems “bugs” since earlier than that, but that story is fun.) But really, when we say “bug” what exactly do we mean? Here’s the precise definition of what … Continue reading
One of the most important things to know about any kind of engineering is: There are some things about the future that you do not know. Obviously it’d be ideal if we were all-knowing and could perfectly predict every consequence of every decision we’ll ever make. But that’s impossible. In fact, it’s so far from … Continue reading
Often, if something is getting very complex, that means that there is an error somewhere far below the level that things are getting complex on. For example, it’s very difficult to make a car move if it has square wheels. You’re going to be spending lots and lots of time figuring out how to make … Continue reading
Okay, so remember our third law? (You can’t break things if you don’t change them.) Well, that has a very important related rule, that every engineer on Earth knows, but sometimes forgets: Never “fix” anything unless it’s a problem, and you have evidence showing that the problem really exists. Of course, most of us know … Continue reading
Okay, so if we never change our software, we can entirely avoid defects. But change is inevitable! Particularly if we’re going to add new features. And after all, one of our goals was to make software easy to maintain, and to maintain software, it has to be changed here and there. In other words, we … Continue reading
So now we know that there is more future time than present time and that software will change as time goes on. Our next law is, once again, axiomatic, and needs no derivation: It is impossible to introduce new defects in your software if you do not change anything about it. This is important–and categorized … Continue reading
Now that we know that the future is important, our second law answers the question, “What’s going to happen in the future?” To any programmer who’s worked for any amount of time, this law will be obviously true once you see it, but it’s still good to derive and prove it. This law is derived … Continue reading
Now that we know what software design is and the purpose of software, the next step is to define the goals of this science of software design. From the purpose of software, we know that when we write software, we’re trying to help people. So, one of the goals of a science of software design … Continue reading
Whenever you engage in some activity, it’s a good idea to have some idea of what the purpose of that activity is. What is the end goal, and why are you doing it? For example, when I sleep, the goal is to be rested. When I talk, the purpose is to communicate and be understood. … Continue reading