Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Increasing Eventual Efficency

David Brion over on the Inquisitive Coder recently posted a great article on measuring developer productivity. In a nutshell the problem he poses is: given two developers with similar tasks over time, if one developer averages 4 hours more per task than the other then who is the better programmer?

Photo by Sherlock77 on Flicker

It could be that the programmer who gets it done faster has more defects. It could be the one who spends more time leaves fewer defects and has cleaner, more maintainable code or it could be they took longer because they overcomplicated the code or took cludgy shortcuts. Scenarios abound.

Eventual Efficiency

The article proposes an interesting measure of productivity called "eventual efficiency" which is how a developer's code impacts the team and the project down the line. Write buggy, brittle, or overly complicated code then your eventual efficiency is low. Write simple, solid, maintainable code and your eventual efficiency is high. Unfortunately he concludes the article saying that at present there is no way to measure eventual efficiency.

While I agree there's no way to put a hard number on it I think that it's possible to get a good idea of the eventual efficiency of each developer. I also think team members can be coached to improve their eventual efficiency.

Steps to observing and increasing eventual efficiency:

#1 Managers Should Code

There's no better way to get a clear picture of the state of the codebase than being in it and fixing defects from each of their team members will give managers an eye into their strengths and weaknesses and show you what they need to do to improve. I've known developers that can excuse their way out of problems so smoothly and cleanly you'd swear they worked in sales; but the code doesn't lie.

#2 Managers Need to Review Code

Managers need to regularly review check-ins of significant size. This will fill in a lot of blanks, for instance:

  • What standards need to be reinforced and what tendencies need to be dissuaded?
  • Who's complicating the code and who's simplifying it?
  • What types of coding does each person do best or, worse case, where do your weaker people do the least damage?
  • What coaching does each person need? Who needs an at-ta-boy (or at-ta-girl) for a job well done?
  • Who needs more frequent code reviews?

Am I saying that managers need to spy on their developers? No, spying is in secret, what I'm saying is trust, but verify, and let them know you're doing it. Managers need to keep their developers accountable. When they do thoughts like "well this is kind of cludgy, but it'll do" or "This turned into a mess but I really don't have time to refactor" will be more easily curbed because the developers will know their manager will be reading their code.

If you're a manager you likely don't have time to be part of the the formal code review process, but spot reviewing code from each of your developers will keep them in sync with the team and help you let them know when adjustments as necessary.

One warning. Coaching should not be a black mark that hurts people come review time. In fact those who respond enthusiastically to coaching and quickly study to fill gaps and modify their behavior should be the first up for raises.  The managers goal here is to build a strong team and a solid code-base and people who work with them toward that goal need to be rewarded. It's the team and the codebase that matter, period; no games and no favorites.

#3 Managers Need Someone To Lean On

Yes I realize #1 and #2 can be difficult to accomplish for many managers by themselves either because of lack of skills or lack of time. That's why managers need a good team lead to them in the loop to the status of the team.

The team lead shouldn't need to be harsh with people; that's the managers job. Instead the team lead should set the tone of the team. They should write solid code and promote standards and best practices and lead by example.
While the team lead should be experienced, they need not be the most productive or knowledgeable person on the team, in fact those people are often too busy to lead effectively. I'm not saying they don't need to be knowledge and experience — they do to hold the respect of the team — but the most critical thing is that they know how to relate to others and are passionate about the quality of the team and the code-base.


It will take a concerted effort to stay in tune with the team and the code but between the efforts of the manager and the team lead a solid view of the eventual efficiency of each developer should emerge. From there consistent coaching and feedback should increase the eventual efficiency of the team.

Site Redesign Complete: Come and See

If you've been by the site the past couple of days (particularly in the evenings between 9pm and 12pm EST) you've probably noticed continual changes being made to the design. It wasn't the ideal way to do it, but it did put a fire under me to get it done... and well, it's done. As a preview for those who subscribe to this feed here's the new logo (I'm really quite proud of it):

If you do subscribe I'd like to invite you to drop by and check out the site... and please, Please, PLEASE leave a comment on this post and let me know what you think of the redesign. Thanks.