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

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

- mike@mountaingoatsoftware.com

The iterative and incremental nature of agile makes an agile approach seemingly less compatible with [...]

- mike@mountaingoatsoftware.com

Velocity can be great for predicting how much a team can deliver in a given period. But it needs to [...]

- mike@mountaingoatsoftware.com

Succeeding with agile isn’t just about knowing where to start, it’s about knowing where to go next—w [...]

- mike@mountaingoatsoftware.com

Here’s what to do when facing a complex user story that cannot be split but is too large for one spr [...]

- Scott Hanselman

As I said on social media today, it's 2019 and I'm updating the Firmware on a Zune, fight [...]

- Scott Hanselman

I'm going to try to finished my Relationship Hacks book in 2019. I've been sitting on it t [...]

- Scott Hanselman

My son and I were working on an Adafruit NeoTrellis M4 Mainboard over the holidays. This amazing lit [...]

- Scott Hanselman

I'm on vacation for the holidays and I'm finally getting some time to play video games. I [...]

- Scott Hanselman

I blogged about DOSBox five years ago! Apparently I get nostalgic around this time of year when I [...]

Meta