Fewer Expert Developers are Better

Home » General Topics » Fewer Expert Developers are Better
Photograph of two people having an argument / strong debate

Today, at a project review meeting, a customer said in no uncertain terms, that fewer, more expert developers are better than a team of devs all with just a couple of years of experience.

I was very pleased about this, because this is something I strongly believe, and in this case, a good part of why the customer was saying this was down to my efforts working on her project. Also you don’t hear it from customers very often – most are not enlightened to these kind of benefits.

It has been said that:-

A good programmer can be 10 times more productive than a mediocre one.

I think I first read this in a book quite a few years ago, possibly Code Complete, first edition, I’m not sure.

Why is this the case? These are my thoughts:

  • Firstly software is not production. Its all design. The only production you do is hit build or publish when you release the software. And you don’t even do that your development environment does the majority of this work for you.
  • So as its all design, using your brain more (to produce a better design) that requires less coding really is useful.
  • If you can produce the same system with ten times less code then there is also a ten times reduction in maintenance overhead and a similar benefit when changes have to be made to the system.
  • If there are only two or three devs working on a system, then the communication overhead and need for meetings etc, is reduced.
  • What if you have too much work for three developers? Get your designer to split your software architecture in such a way that more than one team can work in it without inter-dependencies on the other teams. This is good practice in any case because you will also be reducing inter-dependencies in your software, which is definitely a good thing.
  • Some Agile teams are very light in terms of leadership and design. If necessary, have the business analysts and software architects report to a separate cross departmental leader as well as working in their day to day teams. This is important.
  • It is best if your teams are small but have different personalities within them, for example, somebody really bright who never completes anything, alongside somebody (not quite?) the opposite, a junior and a person who also has responsibility for documentation could be a good mix.
  • We are getting into politics now, but one of the reasons why companies don’t have experienced programmers is that there are not a lot of us around. At one time good programmers were promoted to management after a couple of years, which may well not be a good thing for either party. I’m not going to comment any more on this angle, because my last permanent job was in 1989, I’ve worked for myself as a software developer every day since then.

More information on this subject can be found at http://programmers.stackexchange.com/questions/179616/a-good-programmer-can-be-as-10x-times-more-productive-than-a-mediocre-one

The best experience I can draw from in this regard is my own. I have a customer who uses Indian developers, and my daily rate is almost treble what they charge. However the projects I have worked on are 3 times cheaper overall than the Indian projects and these projects at least partly due to the rework needed to get them ready for go live. I am not knocking the people involved here I’m just highlighted the inefficiencies in the management structure on these projects.

Actual software development is not production like building a car, its a design process like designing a car, even when you write down as much as possible, you can’t write it all down without developing the software. This is why its so well suited to Agile techniques. The only production a developer does is pressing publish at the end when you want to see if the finished product works…

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Top Posts & Pages


Recent Posts

Recent Comments



  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

Too often, agile teams are expected to finish everything every iteration. This expectation is harmfu [...]

- mike@mountaingoatsoftware.com

When a product backlog becomes too big, it hinders agility. Discover four steps your team can take t [...]

- mike@mountaingoatsoftware.com

Pervasive myths about agile get in the way of success. It’s time to bust six of those myths. [...]

- mike@mountaingoatsoftware.com

Agile teams strive to finish work in the same iteration in which its begun. Here’s why that is so im [...]

- mike@mountaingoatsoftware.com

I wrote 25 blog posts during 2018. In case you missed some of them, here are the most popular. [...]

- Scott Hanselman

My Xbox user name is Glucose for a reason. This is a passion project of mine. You've likely see [...]

- Scott Hanselman

I've been really enjoying my Xbox lately (when the family is asleep) as well as some fun Retrog [...]

- Scott Hanselman

So you've been asked to parse some dates, except the years are two digit years. For example, da [...]

- Scott Hanselman

I've been working on a little idea where I'd have an app (maybe a mobile app with Xamarin [...]

- Scott Hanselman

"EditorConfig helps maintain consistent coding styles for multiple developers working on the sa [...]