The Low Cost of High Caliber Developers

Author, Mike Hansen

The Low Cost of High Caliber Developers

There is a vast difference in individual developer productivity.  You could argue that for certain intractable problems that there is an infinite difference in productivity since some developers will just never be able to solve a certain problem in any period of time.  Also, one of the hardest things in software is keeping everything as simple as possible and making the right tradeoffs around technical debt (i.e. short term trade offs).  It takes extremely capable engineers to do that well, the kind that are often orders of magnitude more productive than the average and that bake in extraordinary savings through long term productivity benefits (e.g. compact code base, easy comprehension, fewer mistakes, simple to extend etc.).  Such technical debt prevention has hugely underestimated value over the life of a product.  This is ignored at significant peril, and yet often is.

The range in the cost of development expertise within and across the various models (e.g. in house, near shore, offshore) pales in comparison to the range of productivity of developers.  As with so much in life, you generally get what you pay for.  Many people know this — certainly the technology unicorns.  This productivity spectrum is such that I would argue the costs are (almost) immaterial given the other critical factor:  communication.  Growth in team size leads to exponential growth in the lines of communication:  n(n-1)/2.  Things like huge timezone spreads introduce downside impacts to communication as do things like regionally distributed teams that must work closely on the same efforts.  These regionally dispersed clusters of expertise lead to weak communication pathways across locations (and other social challenges) due to the strong communications that emerge within locations.  Communications is the means to the real end:  rapidly getting the right stuff done right.  Things that negatively impact communication have disproportionately large downside impacts on productivity.

You therefore want to optimize on: 1) fewer lines of communication, 2) the effectiveness of those lines.  With people that have the potential for 5X+ the productivity of a “good” developer, you don’t need nearly as many of them.  These high functioning types will probably be in the top end of compensation but will produce significantly more than the “cheap labor” you might otherwise be tempted to pursue (hint: a massive false economy).  This lets you keep your team size smaller, enabling for exponentially improved communication and teamwork and a huge boost in net productivity.  A small team isn’t sufficient on its own to achieve the most effective communication, but it is required.

There is another benefit.  When you need to scale further, you might still be below the “two pizza” maximum team size, meaning you can add more capacity before you run into a work partitioning problem, requiring otherwise avoidable collaboration across team boundaries (hint: avoidable collaboration is worse than dreaded unnecessary software complexity).  As scale increases, you still have dramatically fewer teams than you otherwise would which leads to extraordinary benefits organizationally.

You can achieve #1 (fewer team members) by ensuring you have extremely high caliber software developers.  #2 (effective communication) means, among other things, you want everyone either in the same place physically (along with the stakeholders) or virtually, where everyone is remote but with solid workday overlap — perhaps a topic for a future post.

These pursuits lead to significant cost economies, improved software quality and increased competitive advantage.  The lower cost model comes, somewhat paradoxically, with the higher cost developer.  It’s rather amazing how frequently battles over this “opinion” are waged.

The following two tabs change content below.

Mike Hansen

Head of Products at Sonatype
Relentlessly working to surround myself with technical people better than me, making sure they have what they need to excel and when appropriate, quickly getting the *#$& out of the way. And, when not busy doing that, playing the piano or looking for the next Colorado 14er to climb (30 bagged to date).

Related posts