What makes a great or good software developer?

We have often wondered and have been asked this a number of times, could it be:

• The three great virtues of a programmer: laziness, impatience, and hubris - Lary Wall, Tom Christiansen, Jon Orwat, (2000) Programming Perl, O'Reilly Media Inc.

Which the Oxford dictionary gives the above words meaning as:

• Laziness, a derivative of lazy a. & v 1. a. unwilling to work; appropriate to or inducing indolence; (of river etc) slow moving.
• Impatience, a derivative of impatient (-shent) a. not enduring with composure (at, with); (of action) indicating such feeling; intolerant of; restless desirous (for anything, to do); hence or cog.
• Hubris n. insolent pride or presumption; (Gk Tragedy) overweening pride towards the gods, leading to nemesis; so ~i'stic a. [Gk]

The book gives the words meaning as:

• laziness The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
  
• impatience The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
  
• hubris Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

I think these are good virtues but how can you apply this to software projects of various sizes and with organizational structures ranging from the evolving chaos to the quality checking every decision and artifact. The most successful software developers I have met have another virtue that is being pragmatic and is captured beautifully in the book by Andrew Hunt and David Thomas (2000), The Pragmatic Programmer,  Addison Wesley.

For me the high lights are the following:

• Continuous Testing.
• Design and implementing software over just implementing software.
• Being flexible towards the business needs or requirements.

Continuous Testing

This is the idea of having small unit tests associated with each module of code that proves the behavior of the code. This can be use to ensure all changes have not adverse effect and also Test Driven Development changes the way developers approach a problem as they have to think a little about what they are going to do and create a skeleton of a test and not worry about the detail until they come to develop that behavior.

Once a project as a number of code modules and associated tests this can be controlled by a build system and help the automation of the project allowing anyone to get a release from the Source Version Control System, verify the code passes the test and deploy to the appropriate environment.

Design and implementing software over just implementing software

This is one we really believe in but for some reason is the hardest to convince people to adhere to has people believe that is takes to much time or cost to much money. When I say design I mean fully documented so as the team scales or changes everyone can read the design specification and get fully up to speed.

This does vary depending on the industry that the software is being developed for but I would hope that the software engineering industry would pride itself in doing design before implementing the code. There are lots of tools that can help in doing software design, our favorite is Enterprise Architect by Sparx Systems.

Being flexible towards the business needs or requirements

This is the main reason we insist our development teams we work with to design their software and unit test the software. This allows us and the companies we work with to say yes to our clients when they change their minds or a deal relies on the System working in a particular way.

That only gets you half way to achieving this goal. You also need a software architecture design that the developers are will to follow and a good process to identify the impact of the change to know how much it going to cost.

If the cost is to much it can always be put into the softwares roadmap so your clients know you have listened. The main reason I like to develop flexible and configurable software is to be able to say yes to our clients.