People who work with me tend to realize, quite soon, how much I strive towards trying to build simple software: simplicity keeps code reusable, open and easy to maintain or evolve — the toll abstractions take is generally a heavy one, and I try to avoid it every time I can (been guilty of building complex, and some time complicated, stuff too!): to me, simplicity is king.
Now, I was really excited to find out that the main dev behind Bugzilla, the OS bug tracker, wrote a book about simplicity in software as – I thought – he could give me a really good overview of keeping things simple in such a huge (and dated) project.
So I went ahead and bought myself a copy of “Code simplicity” and, to be honest, it was a fairly intriguing book: nothing groundbreaking but, at the end of the day, it is a solid book that gives you some inspiration.
Even though you might not agree with everything the author puts on the table, you will find yourself going through some pearls on software design and how to design good software, through simple & coincise code:
The difference between a bad programmer and a good programmer is understanding.
Programming, in essence, must become the act of reducing complexity to simplicity.
You must not design by committee.
The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change.
nearly all decisions in software design reduce entirely to measuring the future value of a change versus its effort of maintenance.
It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.
there is a difference between designing in a way that allows for future change and attempting to predict the future.
Code should be designed based on what you know now, not on what you think will happen in the future.
the more you code, the more defects you will introduce.
Never “fix” anything unless it’s a problem, and you have evidence showing that the problem really exists.
The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces.
Names should be long enough to fully communicate what something is or does without being so long that they become hard to read.
Consistency is a big part of simplicity. If you do something one way in one place, do it that way in every place.
Some projects start out with such a complex set of requirements that they never get a first version out. If you’re in this situation, you should just trim features. Don’t shoot for the moon in your first release — get out something that works and make it work better over time.
Some of the best programming is done on paper, really. Putting it into the computer is just a minor detail.
Comments should explain why the code is doing something, not what it is doing.
When presented with complexity, ask, “What problem are you trying to solve?”
As a “secondary read”1 I think this is a pretty solid book!
- When I say “secondary” I mean one of those backup books you read throughout a long span of time, nothing that deserves your undivided attention while reading but is still valuable to you ↩