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?”