Developer Productivity

I've read a number of articles on developer productivity, but NONE of them have helped me increase it from a perspective of a "C" level position. There is just too much organization and turfs for me to drill through to figure out if a certain team as a whole stinks, or if I'm responsible for their poor productivity by not creating and ensuring a path to success.
Here are a few articles I've read but as you'll see (if you've ever managed multiple teams), they dont come close to depicting the true picture:
(image from http://www.worth1000.com/emailthis.asp?entry=387650)

  1. http://forums.construx.com/forums/t/186.aspx
  2. http://wsdj.sys-con.com/read/43343.htm
  3. http://www.solidstategroup.com/page/1623
  4. http://fc-md.umd.edu/projects/Agile/Maurer.htm

This topic and problem is as old as software development itself. There's even a whole field around it ie software engineering with the million dollar question being how to make software development an aspect of engineering whereby building major software systems boils down to using sound principles and processes. This is in contrast to the "heroics" rule where a star developer delivers the goods while the majority of the team rides the boat as tourists.

The jury is still out on the "perfect process and principles for developing software", with agile development being the new thing. In the end, being responsible for delivery of technology projects remains a headache at best. A GOOD article on the subject of productivity is:

http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx

My two cents on the topic are:
1. All Developers must have an incentive to be productive. This means:
a. Use logical metrics to measure productivity ie Do not use Lines of Code as a measure etc etc, as they certainly dont hold true in today's coding world of smaller is better. Use peer feedback and be careful when getting feedback from the team manager. Word of advise on team managers - sometimes they hide their faults by throwing the blame on others or are incompetent to a level where they do not understand what productivity is.
b. Dont let poor performers bog down the good ones. If the good developers are left chasing bugs created by prolific bad coders, they will only feel frustration. In the end, the good developers will be frustrated and burnt out while the bad ones will feel on top of the world. End result - attrition of top talent!
c. Dont assign average individuals to be leads or managers. They're dead weight AND they generally frustrate top talent in the team. Get rid of them ...yes, move them out. Dont wait for a major disaster to take action.
d. Ownership. Ensure code is OWNED by developer(s). If the code base is small, the team lead can be the owner ie all checkins MUST be reviewed and approved by him or her. If the code base is large, distribute code modules amongst key individuals. Unowned code is like a rental car, there is no incentive to be "nice" and drive with care....Ops, did i let a secret out :)
e. Keep QA close to your ears. They are optimally situated to report back on the overall quality of the application. Listen to them and mentor them. Using QA resources, a process of proactively identifying careless mistakes and developers responsible for them is a key benefit. This is a key component of measuring productivity

2. Enforce tools of the trade ie Source code repository, Bug Tracking system, Project management system. The ones I'm fond of are: SVN, Trac and Basecamp. Needless to say, best practices must be followed. This works miracles when tracking down escalations.

3. Recruit only the best. Taking shortcuts when hiring in crunch is generally the excuse for having a team of mediocres....dont fall in the trap.

4. Keep in close touch with all developers. They need to know that they can always escalate concerns over their managers when they're not being heard. But keep your managers in the loop until its clear the incompetence is at the mid management level.

5. Encourage developers to be vocal. Business Analyst need to know they'll have hell coming down if they screw up - as they'll stir up a storm in a beat if development doesnt deliver no matter where the flaw is. Note of caution: Dont ever let it become a "us vs them" argument, by emphasizing objectivity and professional communication.

6. Hire or promote an excellent developer to audit coding and processes being followed in different projects after every major milestone, where possible. This individual must be a killer, someone others can learn to respect because of his or her command on logic and technology. Otherwise it's just another position and overhead everyone in the org despises (I'm not a fan of creating COE's ie centers of excellences unless youre running a large firm). If you're at an executive level position in the technology department, than you're essentially offloading some of your own responsibilities here ...but lets face it, todays business world requires executives to burn their days in meetings.

Comments