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

Categories

Recent Posts

Recent Comments

Archives

Blogroll

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

Doors are now open (for a limited time only) to my new course: Estimating with Story Points.

- mike@mountaingoatsoftware.com

In this final video on creating estimates with story points, I help you overcome one of the biggest

- mike@mountaingoatsoftware.com

This video helps you align stakeholder and team expectations when creating estimates (and those esti

- mike@mountaingoatsoftware.com

Just released: Free videos to help teams solve problems when creating estimates with story points.

- mike@mountaingoatsoftware.com

- Scott Hanselman

I got a lovely email from a reader named Steven who has been doing .NET for many years and is excite

- Scott Hanselman

I've long said, as a fan of the console and text mode, that the command line is underloved. You

- Scott Hanselman

I've talked about the dotnet-outdated tool before but now it's, ahem, outdated. It's

- Scott Hanselman

I've often asked for my Windows Terminal's settings.json (formerly profiles.json) so I kee

- Scott Hanselman

A few years back I had a lovely podcast conversation with technical leader Keavy McMinn. Sometimes I

Meta