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

It can sometimes be a challenge to get people to attend and then participate in sprint reviews. Here [...]

- mike@mountaingoatsoftware.com

The standard “As a...I...so that…” user story template has stood the test of time. Here’s why each o [...]

- mike@mountaingoatsoftware.com

From helping teams understand the boundaries of self organization to creating safety around things l [...]

- mike@mountaingoatsoftware.com

Your team is probably spending too much time in sprint planning meetings. Here’s how to spend less t [...]

- mike@mountaingoatsoftware.com

Debating between Scrum and Kanban? Guest author Brendan Wovchko offers five advantages Kanban has ov [...]

- Scott Hanselman

There's been a lot of folks, myself included, who have tried to install VS Code on the Raspberr [...]

- Scott Hanselman

I don’t speak in hyperbole very often, and I want to make sure that you all understand what a big de [...]

- Scott Hanselman

I recently needed to refactor my podcast site which is written in ASP.NET Core 2.2 and running in Az [...]

- Scott Hanselman

.NET code (C#, VB, F#, etc) compiles (for the most part) into Intermediate Language (IL) and then ma [...]

- Scott Hanselman

Almost ten years ago I posted abut the SpaceTec SpaceOrb 360 Controller and that was 15 years after [...]