Code Simplicity

Unforseeable Consequences: Why We Have Principles

July 14, 2008

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 possible that if you predict…

FOSSCoach 2008

July 1, 2008

If you’re going to be in Portland, Oregon or attending OSCON and you want to hear me talk, I’ve proposed a session for FOSSCoach called Code Simplicity: Software Design In Open Source Projects. Registration for FOSSCoach is free, but is limited to 100 people, so sign up if you want to come. -Max…

The Never-Shipping Product

June 2, 2008

When you work as a professional programmer, you almost always know somebody (or are somebody) who’s going through one of the most common development horror stories in the book: “We started working on this project five years ago, and the technology we were using/making was modern then, but it’s obsolete now. Things keep getting more and more complex with this…

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…