Software Development Productivity

Project X was invited into a conversation last week with some senior folks at various organizations on the topic of software develpoment productivity.  First, thank you Mark for including Project X in the conversation.  It has sparked some interesting debate of which I would like to share some and invite more from you.  Mark’s original premise as the basis for the discussion was this:

  • a junior person is less productive because they are inexperienced
  • a senior person is less productive because they get distracted/involved in other activities but is way more productive than a junior
  • an intermediate developer is the most productive

and therefore you could adjust the mix of your team by increasing the intermediates and eliminating some seniors (most expensive) and juniors (least expensive) and re-balancing your team for the same total throughput at a lower cost.  Ie. function points per $ or KLoc (thousand lines of code) per $ not per hour.

This is a great question.  My first observation is that you need to make some differentiation on the type of software development: Custom or Integration.  Another direction the conversation can go is on-site, off-site and off-shore and the difference that mix brings.  And last what is the goal of the development team and the organization they work for and support.  I am going to leave the last two to another couple of posts upcoming and focus on the first for our first conversation.

My first thoughts and only analytical are the following – custom software development:
Identify at each level the following and try to quantify with some sort
of number system and then bring it all together to define productivity
(first step is define productivity to you your organization and
customer).  The reason is as someone moves to a more senior role there
are other activiteis they often become involved in that support others
productivity on code development:  So here are some thoughts:

  • cost per hour/day/month or year
  • avg # of lines of code / period or alternatively function points (which may be a better measure here)
    • This should cover by default the different amount of time that
      people spend at each level writing code, how hard they work, etc.
  • Avg defect, rework or bug qty and attach an estimate of cost.  This
    could be covered in the above if that is end production ready items.
  • Amount of oversight needed to manage the person (in support of loaded cost)
  • Training cost (the more senior you are the more likely that training becomes more specialized and expensive)
  • Ability to understand requirements
  • Ability to work with end -users
  • Other intrinsic value to the organization (this is where each
    organization needs to identify the value on some of the soft values
    that are so crucial in having good knowledge workers)

This should give you a starting point, but we need to be careful on how
this is applied as people are not numbers and everyone on your team has
nuances and value that go beyond the above.  My favorite observation is
that it is near impossible to find a good solution architect.  And
ultimately they set the downstream tone of a project.  So they may not
even write a line of code and how do you integrate that into the
model.  I know a select few who can do solution architecture and then
want to stay around and help write the application.  I know lots of
tech leads that do this, but not many true solution architects.

So I welcome your thoughts as we work to understand and build some insight around Mark’s original questions.

Leave a Reply

captcha *