Code Simplicity

The Second Law of Software Design

March 3, 2008

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 from things that we know…

The Goals of Software Design

February 29, 2008

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 should be: To allow us…

The Purpose of Software

February 27, 2008

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. Similarly, when we write software,…

What Is Software Design?

February 25, 2008

On my last blog, one of the commenters very correctly pointed out that I hadn’t actually told you what I meant by “software design.” And, in fact, looking around the web a bit, I’m finding that what I mean by “software design” isn’t fully covered by most current definitions. For the sake of this definition, let’s say that the process…

The Primary Law of Software Design

February 21, 2008

Ideally, any science should have, as its base, a series of unbreakable laws from which others are derived. What is a law? Well, in the field of science, it’s something that: Is universally true, without exception. Predicts phenomena that, when looked for, will be found to exist in the real world. Some of the best laws are axiomatic, a big…

There Is No Science Of Software

February 19, 2008

What we think of today as being “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 modern founders of “computer science.” Computer Science is actually the mathematical study of information processing. It is not, as some…

Simplicity and Strictness

February 13, 2008

As a general rule, the stricter your application is, the simpler it is to write. For example, imagine a program that accepts only the numbers 1 and 2 as input and rejects everything else. Even a tiny variation in the input, like adding a space before or after “1” would cause the program to throw an error. That would be…

When Is Backwards-Compatibility Not Worth It?

February 11, 2008

This title might seem a bit like a contradiction to my last post! Well, you really shouldn’t break your API, if you can help it. But sometimes, maintaining backwards compatibility for any area of your application can lead to a point of diminishing returns. This applies to everything about a program, not just its API. A great example of the…

Ways To Create Complexity: Break Your API

February 7, 2008

An API is a sort of a promise–“You can always interact with our program this way, safely and exactly like we said.” When you release a new version of your product that doesn’t support the API from your old version, you’re breaking that promise. Above and beyond any vague philosophical or moral considerations about this, the technical problem here is…

What Is Overengineering?

January 29, 2008

Software developers throw around this word, “overengineering,” quite a bit. “That code was overengineered.” “This is an overengineered solution.” Strangely enough, though, it’s hard to find an actual definition for the word online! People are always giving examples of overengineered code, but rarely do they say what the word actually means. The dictionary just defines it as a combination of…