Blog article
See all stories »

Why the 10,000 Hour Rule Matters in Software Development

Introduction

I’ve just recently finished reading two books. The first was “Bounce: Mozart, Federer, Picasso, Beckham, And the Science of Success” by Matthew Syed. He is a British journalist and broadcaster who was the English number one table tennis player for many years

In the book he made a number of references to another book which was “Outliers” by Malcolm Gladwell. As I enjoyed Bounce so much I then bought this book.

The essential premise of both books is that talent is a myth and that people reach the pinnacles of their chosen sport or profession through hard work and opportunity. Both books present very convincing evidence for this premise.

However, not everybody is convinced. There are still many people who will argue that talent is an innate trait in a person.

The 10,000 Hour Rule

Regardless of who is right there is a universal agreement that, with or without innate talent, you cannot reach the top in any complex activity unless you have put in 10,000 of hours of purposeful practice. This has also become known as the 10-year rule because that’s roughly how long it takes to put in 10,000 hours of hard practice.

Both books look at the lives of a whole range of top achievers, from Mozart to Tiger Woods, to show how they got to the top with a combination of hard practice and a set of circumstances that enabled them to dedicate over 10,000 hours to their chosen activity.

So regardless of whether they had talent or not, they still had to put in 10 years of dedicated, purposeful practice in order to reach the top.

What Has This Got To Do With Software Development?

Software development is a very complex activity that also fits the 10,000 hour rule. You do not become an expert developer overnight. To reach the elite level of development you will need to have put in 10,000 hours, or about 10 years, of deliberate practice.

This doesn’t mean that everybody with 10 years development experience is automatically an expert. On the contrary, very few are. It’s not just a question of “How long” but also of “How”.

Very few developers work in environments that encourage and push their developers to constantly get better. They are usually employed for the skills they already have and year by year there is no major advancement in their skills. Of course they learn more and will get a bit better but not significantly better.

Freelance contractors are often seen as “experts” but I think this is due to their high cost. I think many people assume that high cost = high calibre skills. In fact, most contractors are no more than average developers because they have nobody investing in their skills development and pushing them to be better. They are usually focussed on their day rate earnings and have little time to invest in getting better.

Top performers in any activity will always want to get better. The same is true for the top developers. They will develop their strengths but more importantly they will focus on improving their weakest areas. Standing still in this business is a sin. If a developer is not getting significantly better each year then they have no chance of becoming a high quality developer.

Why Does this Matter?

There have been numerous studies into the productivity of developers. It is generally accepted that there is an order of magnitude difference between poor developers and the best developers. The most commonly cited factor is 10x. (see Steve McConnell – 10x Software Development)

There are others who believe that the difference is even greater. A view I subscribe to. The reason is that most studies look at the productivity of writing code but forget to mention the effects this has on the lifetime costs of the code.

Great developers do things quicker, with significantly less code and with far fewer defects. Not only do they save you money now but they will also save you money through the life of the system in support and maintenance costs because their code will be easier to understand and easier to modify.

Most studies also don’t take into account the damaging effect of poor developers. Often the code written by these people has to be rescued, or rewritten, by the top developers. So, not only are these people almost wholly unproductive, they also suck productivity out of the top developers.

The bottom line is this. If a great developer produces code at a minimum of 10x faster than a poor developer then you get the benefit of the software 10x quicker. What’s the financial gain from doing that? And what is the lifetime saving for having good software over poor software?

This is why the 10,000 hour rule matters in software development.

What Can YOU Do About It?

I would hope that it’s obvious that you need to make sure that you have some people with upwards of 10 years experience. But experience by itself is not enough. It must be good experience and there should be evidence of how they have continually improved themselves. A 10-year veteran with poor skills will probably cause more damage than a junior developer who is keen to learn.

It’s unrealistic to expect to have teams comprised solely of highly experienced developers. There just wouldn’t be enough room for all the egos! However, you certainly want your lead people to be experienced veterans, with the rest of the team comprised of people well on their way to serving their 10,000 hours.

Everybody in the I.T. business also has a duty to bring on the next generation of developers. These up and coming developers need to be able to serve their 10,000 hours in an environment that encourages (even cajoles) them to become great developers. These are the stars of the future.

You therefore need to have a team environment that sets high standards, promotes skills development and doesn’t tolerate poor practice. The ideal situation you want to achieve is where the teams take it upon themselves to continually get better.

At our company we run annual Best Practice initiatives across all the technical teams. We let the teams decide what things they need to improve. They then propose them to the management for sign-off and then we reward them for achieving these.

Of course there will be some people who will read this and immediately think “But if I invest lots of time and money to grow great developers they will just leave for more money at the first opportunity”. Let me suggest why this is flawed thinking.

Firstly, even if they do leave you, for however long they have been with your organisation you will have benefitted from getting higher quality code delivered 10x faster. That is worth the price of admission alone.

Secondly, just like Usain Bolt wants to set more records or Tiger Woods wants to win more golf majors, good developers want to get better. If you offer an environment that pushes people to higher levels of achievement then they are more likely to stay with you.

Money never features as the highest priority for people. Career development and recognition always rank higher.  By demonstrating a commitment to developing their skills to the highest level you are creating a challenging environment that the best people will love. And if a few people drop by the wayside because they can’t keep up then so be it. Maybe they are the people that you don’t need.

Summary

Software development is a highly complex activity. Unfortunately there are no barriers to entry to become a programmer. This is why there are so many poor developers around.

If you really want to improve your software development capabilities and get better at delivering projects on time then it really does pay to recruit people with lots of good experience. Where else in your business can you get a 10x, or greater, productivity increase for little or no extra cost? 

7398

Comments: (1)

A Finextra member
A Finextra member 27 November, 2012, 10:20Be the first to give this comment the thumbs up 0 likes

The gap between poor developers and the best developers has only widened with time, driven primarily as a result of modern programming languages being far more forgiving than their predecessors, resulting in the continued erosion of the barriers to entry that were traditionally associated with pursuing a career in this field.

The Best Practice initiates run by your company appear to be a good way of tackling the general issues caused by complacency amongst poor developers, although I suspect that the success of these initiates lies heavily in the presence of enough talented developers so as to inspire the lesser developers to improve, which only reinforces the importance of talent within any organisation.

The challenge remains for hiring managers to suitably identify the most competent developers during the interview process and in reality it’s far easier to identify raw talent than it is to evaluate underlying attitudinal traits, especially as most interviewees will simply say what they believe you want to hear.

Whilst it’s an admirable notion that poor developers can become better in the right environment, there is also the harsh reality that some people are just not cut out to be developers and no amount of nurturing and support will help them to become one of the best developers. This is an unfortunate albeit expected side effect of the reduction in the barriers to entry that have occurred over time.

Blog group founder

Member since

0

Location

0

More from member

This post is from a series of posts in the group:

Business Knowledge for IT

This community aims to provide links, resources, book suggestions, tips and insights to facilitate learning and development of IT professionals in financial services, and to develop a forum for IT professionals to exchange views on various related items.


See all

Now hiring