Chappell's Fifth Law of Programming
(One from the archives. I wrote this ten years ago. I think it still stands.)
After quarter of a century of tinkering with computers and 15 years of programming them to earn my living, I would have to say that some observations are so obvious that I almost feel it's redundant to speak them. This law would certainly fall within that realm. But, repeated observation of real life in the I.S. industry, on both sides of the Atlantic, has given me cause to believe it necessary to share it.
Simple is good.
As a rule of thumb, when considering designs or development approaches, always err on the side of simplicity whenever possible. Naturally, there are a few things in this life that are blisteringly complicated, but unless you really are a rocket scientist, it's unlikely that what you do is one of them.
I have seen far too many designs ruined for the lack of simplicity. I have witnessed far too much code that spends more time trying to be clever rather than getting the job done. This law pretty much goes hand in hand with my second law of programming. In order to write code that you can read at 2 a.m. you need to write in a straight-forward fashion. To be able to write straight-forward code, you need a simple design. You need a design that solves the problem at hand and doesn't play the "how many patterns can I squeeze in one UML diagram" game.
Simplicity also has the added benefit of producing systems that work better and are ready sooner. Simpler systems have less components, less relationships between the components to manage and a much lower chance of adverse behaviour between components. If programmers produced physical items, we'd describe them as streamlined and with less moving parts!