Code Simplicity

Specific Solutions

April 22, 2008

So, I’m a huge Kyle XY fan, and I was entertaining myself this morning by watching the various “behind the scenes” clips that they have on the website. Of course, before each clip was an ad–the same ad every time–for The Sims. No matter how silly the ad may be, being forced to watch it over and over did eventually…

Complexity and the Wrong Solution

April 14, 2008

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 the car work, when really…

Truncated Posts in RSS?

April 10, 2008

Hey everybody. So, some of my posts are rather long, and so I truncate them with a (Read More…) link that takes you to the full post. That link also shows up in the RSS, as a (more…) link. For the frontpage of codesimplicity.com, I think that’s pretty useful–it makes it a lot easier to browse the various articles. But…

Instant Gratification = Instant Failure

April 9, 2008

The broadest problem that I see in the software industry is that companies are unwilling to engage in strategies that only show results in the long term. Or, more specifically, that organizations are unaware that there is any such thing as a long-term strategy. In the US, it’s probably a symptom of a general cultural problem–if an American can’t see…

If It Ain’t Broken…

April 4, 2008

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 this as “If it ain’t…

The Fourth Law of Software Design: Complexity vs. Ease of Maintenance

March 10, 2008

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 will be making changes. So…

The Third Law of Software Design

March 7, 2008

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 as a law–because defects violate…

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,…