The Cathedral and the Bazaar

In 1997 Eric S. Raymond wrote an essay (later turned into a book) entitled "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary".

In the essay Raymond compares and contrasts two different open source models and proposes the idea that one of the reasons open source is a beneficial activity is because "given enough eyeballs, all bugs are shallow".

Also presented are 19 lessons gained from various experiences in software development about good practices in software development.

I'm not going to go through all 19 lessons but I have picked out a small number that particularly resonant with me.

Good programmers know what to write. Great ones know what to rewrite (and reuse)

When we first become developers (I'm assuming that anyone taking the time to read this is a good one) we want to write code to solve every problem were presented with.

While this enthusiasm for plying our trade never leaves us experienced developers do develop a healthy lazy-ness for not wanting to write code to solve problems that were very effectively solved long ago.

This laziness will give rise to two effective instincts, recognising when someone else must have already written code to do this, and recognising when code your writing has the potential to be applicable in many situations.

To paraphrase a famous writer "Talent imitates, Genius Steals".

Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away

The first solution we provide to a problem will almost always be comprised of more code than is necessary to achieve the result.

Because of this we should not stop thinking about the problem when we arrive at this first solution, instead we should set ourselves the goal of trying to get to the same outcome with less code.

There is obviously a balance to be drawn, developers are often obsessive people who could very easily never be happy to say something is finished. 

We don't necessarily have to achieve the optimal solution first time round, what we do have to realise is that if were adding more code we are adding more potential defects, we are probably adding more features not refining the ones we already have.

The goal of re-factoring should always be to end up with less code than when we started, the solution should be come more readable, more understandable and simpler.

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected

If code is going to be re-usable it first of all must solve a problem that exists elsewhere in the code base. Secondly it must be written in such a way as to make it loosely coupled from the code it is serving and solving the problem for.

In many ways software development is a repetitive activity, many projects your involved in will require solutions to the same or similar problems to the ones you've faced in the past.

Its also true that its not always easy to predict when your faced with a problem whether or not its the kind of problem you may face again in the future.

If you write loosely coupled cohesive code I guarantee that you will end up using this code in a situation you couldn't have predicated at the time when you wrote it.

Many people will be amazed when an experienced developer quickly provides a solution for a new feature, is it that this developer is able to write code at a fantastic rate? Or is it another example of healthy laziness where instead this developer is reaching into the toolkit of code he or she has amassed over the years?

All of these points are pointing towards the fact that as developers our job isn't to just produce more and more code. We are not in an industry where producing more and more of our raw product is the aim of the game.

We are actually employed because were smart people who can solve problems, and the best solutions to those problems are born from a desire to not have to write so much code.

Be smart, be lazy.