«    »

Achieving Excellence in Software Development

What is excellence in software development and how can you achieve it? This is a question of interest not only to software developers, but also to managers of software teams.

I recent read the book First, Break All The Rules: What The Worlds Greatest Managers Do Differently which provides some great insights into this question. The book's content is based on in-depth interviews of over 80,000 managers that sought to determine what the top-performing managers across different industries and companies do differently than the majority. One point that was not surprising is that the greatest managers focus on achieving excellence within their teams - they are not content with merely average performance. But the strategies that these managers use in the pursuit of excellence do differ from what conventional wisdom suggests.

Excellence is not achieved by studying and avoiding failure

"Conventional wisdom asserts that good is the opposite of bad, that if you want to understand excellence, you should investigate failure and then invert it. ... Managers are far more articulate about service failure than they are about service success, and many still define excellence as 'zero defects'." (page 102. All quotes from "First, Break All the Rules")

"You cannot learn very much about excellence from studying failure. Of all the infinite number of ways to perform a certain task, most of them are wrong. There are only a few right ways. Unfortuntely, you don't come any closer to identifying those right ways by eliminating the wrong ways. Excellence is not the opposite of failure. It is just different. It has its own configuration, which sometimes includes behaviors that look surprisingly similar to the behaviors of your strugglers." (page 157)

Studying defect-ridden code may help you recognize design and coding approaches that cause defects, but this provides limited benefit if any in teaching you how to produce solid code. Furthermore, achieving zero defects in your code or in your software product is not a sufficient condition for excellence. Preventing and eliminating defects is important, and learning how to do so will make you a better developer. But there is much more to developing great software than correctly-behaving code: Is the code understandable? Easy to extend and alter? Easy to install or promote to production? Easy to diagnose problems in? Easy for users to use? Does it do what the users want and need it to? Looking at poor-quality or even average code will seldom reveal how to produce great software that can answer all these questions in the affirmative.

Learn excellence by studying the best

"The best way to investigate excellence is simply to spend a great deal of time with your top performers." (page 159) This statement is targetted at managers, who need to determine what factors contribute to excellence in order to be able to promote and recruit it. But the concept is equally applicable to software developers with no supervisory responsibility. In order for you as a developer to grow towards excellence, you need exposure to it. Studying great software developers and great software is one way of gaining that exposure.

If you are inexperienced, you face a chicken-and-egg problem of needing to first identify greatness in order to learn from it. I recommend starting with widely-recognized sources such as books, blogs of well-known developers and consultants, training courses, conferences, and open-source software as a source of code to study. You can also try to find one or more experienced developers within your organization to act as a mentor. The quality of such resources will vary, but over time as you learn and gain experience you will be able to better identify excellence.

The difficult part of this process is that mere exposure to excellence is not enough. You must reflect on what you are seeing in order to extract those crucial insights into the nature of excellence, and determine how you can apply them. One example of this from my own experience is from a number of years ago when I was trying to better understand how top developers do design and coding. I picked up the book Refactoring: Improving the Design of Existing Code in order to learn about refactoring, but while reading it gained some important insights into how the author approaches design. In fact, I found that to be the most valuable aspect of the book.

Another example is from a presentation I heard from Bob Beck, one of the core set of developers for the OpenBSD operating system. OpenBSD is best known for its focus on security, and I was able to gain some insights into the processes used by the core developers to achieve this. One key process is their regular use of code audits across the entire code base which are triggered when a defect or potential security hole is found somewhere in the code due to a bad coding construct (such as incorrect use of a C library function). The construct is first identified by root cause analysis of the problem, and then the entire code base is inspected to eliminate any other occurrences. More details on this process are available at http://www.openbsd.org/security.html.

Excellence takes talent

"Skills, knowledge, and talents are distinct elements of a person's performance. The distinction among the three is that skills and knowledge can easily be taught [or learned], whereas talents cannot. ... Skills are the how-to's of a role. ... Your knowledge is simply 'what you are aware of'. There are two kinds of knowledge: factual knowledge - things you know; and experiential knowledge - understandings you have picked up along the way." (page 83)

"Talents are different phenomena altogether. Talents are the four-lane highways in your mind, those that carve your recurring patterns of thought, feeling, or behavior." (page 84)

People can achieve average performance without talent, but true excellence requires talent. Talent is not, however, a binary have-it-or-not phenomena. There are a multitude of talents, and different roles require a different mix of them. One of the key points I took from the book is that everyone is talented - everyone has a particular mix of talents - and great managers excel at putting their people into the role best suited for their talents.

Even within software development, there are a number of roles requiring different talents. Or another way to look at it is that people have different talents which require different roles. One person may like to have their work clearly defined and prefer to start with a clear requirements or design specification. Another person might be careful and methodical, making them well-suited for doing code reviews or testing. Another person might be visual in nature and like designing or creating user interfaces or web sites.

The key for each of us is to identify our talents and make sure that the roles we take on fit with those talents. One way to determine this is to recognize when you are working on tasks that are a struggle, or are painful, or are de-motivating for you to do. These are potential signs that this type of work does not mesh with your talents.

Excellence takes experience

Across "diverse professions, it takes between ten and eighteen years before world-class competency is reached." (page 185). Even in someone with the perfect blend of talents, it takes time to amass the skills, factual knowledge, and most importantly experiential knowledge that are necessary for excelling at a role.

Many companies and even entire industries, however, pressure people to move up the organizational chart. Fancier titles, bigger perks, and probably most importantly larger salaries are all magnets attracting people up the corporate ladder. This not only prevents people from building sufficient experience for expertise in their original role, but also runs the risk of moving people out of a role for which they have the right talents, and moving them up into a role for which they are not talented. The net result: a formerly excellent employee becomes only an average or poor performer. This is a common problem in I.T., where star developers are promoted into team leads, project managers, or architects that require a significantly different set of talents, skills, and knowledge. I discussed this particular issue recently in my article To Code or Not To Code. This general problem has been identified a long time ago as the Peter Principle: people are promoted to their level of incompetence.

The book offers several suggestions at a corporate level for combating this promotion pressure. One idea is defining levels of achievement within a role - such as junior, intermediate, and senior software developer, so that promotions can happen without changing the nature of the role. A second idea is to offer wide, overlaping pay scales, so that an excellent senior developer, for example, would make significantly more than an in-experienced first-level manager.

Achieving Excellence

A summary of the steps for achieving excellence are as follows:

  1. Find a role that matches your talents.
  2. Develop your skills and knowledge for the role by studying the best.
  3. Spend the years gaining the necessary experience.

If you find this article helpful, please make a donation.

One Comment on “Achieving Excellence in Software Development”

  1. Steve Mills says:

    Excellence is a combination of telling yourself the right stories and gaining the right internal programs to be able to maximize an opportunity when it arises.

«    »