« Conway's Law | Main | The Beginning of Personalization »

Monday, December 13, 2010



This is the reason why I like to advocate lean/agile approaches to software development. Note that I'm not saying other ways cannot work. :)

It really doesn't matter if you are being productive using some fancy metric. The key thing for me is customer satisfaction. Are you solving the right problems to achieve this?

It's extremely easy for us software developer folks to get stuck on some non-essential detail that really doesn't deliver much value to the customer. Leaner, less prescriptive approach to software development forces us to focus on the right things.

Benjamin Manes

This is what I love about Pivotal Tracker. Its simple, provides visibility & priorities, and isn't process heavy. As a developer its a dream as it lets us manage tasks as either in-progress, scheduled (backlog), or unscheduled (ice box). We can provide weekly status updates based on our velocity, plan out projects, and easily adjust based on changing need.

I love it and I absolutely hated the mico-managing, proccess centric, painfully slow VersionOne. I also found the uber macro-management with clear no direction and secrecy frustrating, but at least it enabled the freedom to be productive. But Pivitol, wow... that's one tool that will make your developers happy.

(No association, just happy user)


So true, actually i got adrenaline rush when working with great team and great framework with magical syntax.. so all you need to do is write wht u wnt to happen instead of writing how it should happen


Have you read How to Measure Anything by Douglas Hubbard?

Dan Pritchett

Nope, but I will add it to my reading list. Thanks!

Sri Shivananda

While there may not be a universal numeric index, productivity is clearly visible, comparable in context and addressable / tunable.

I have sometimes used a negative measure of "time wasted" in non code producing tasks as a close enough proxy.

Productivity comparison across developers is a somewhat futile task. There are developers who are 10 times more "productive" in the same environment due to the difference in education, training, planning, discretionary effort, creativity etc.

I believe measuring same developer productivity and eliminating or optimizing time spent in activities like developer desktop setup, workspace setup, builds, server start-up, hardware provisioning, dealing with engineering rot coming for bad code hygiene, deployment etc. should always be a goal for engineering leaders.

Then there are personal productivity optimizations like how often you check email, how much time you spend in meetings or how you manage time slicing on a project that impact how productive a developer is as well.

Account Deleted

Who was it that said LoC should be counted as cost, not as deliverable? Wise words...

Farhang Kassaei

It depends what type of productivity is measured and how it is used (and by whom). I agree that defining and measuring productivity per developer (micro-productivity) is next to impossible, they are simply too many variations, it is like measuring the total distance a soccer player runs during a game - it does not matter. However there is notion of macro-productivity (much like what economists measure for each country). But it has to be measured as an aggregate and has to be used to improve the overall software engineering discipline in a unit (not to judge individual performance by). One simple (or simplistic?) was is to divide unit of output (one application - I know we don't even agree what an application is :-) divided by input (developer*hours). It is crude, and it MUST not be used as an absolute measure, but if it is measured for the same team building three, four applications, it gives you a good indication of how your platform (tools, processes, libraries, runtime etc.) enables your people (or conversely how effectively your people utilize your platform)

The comments to this entry are closed.