
Scott Bellware: A Simple, Definitive Metric of Software Development Productivity - woan
http://blog.scottbellware.com/2011/03/simple-definitive-metric-of-software.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+sbellware+%28Scott+Bellware%29
======
ibejoeb
Under Non-Value-Added Work:

> Here are a few things that we do that are waste...

> Teasing apart code to understand how it works, especially when this effort
> is repeated whenever a team member confronts that code

I can't think of a circumstance where close inspection of the code is not a
_necessary_ step toward understanding it. The author does not seem to indicate
that he means rewriting, but even if he does, there is typically value in that
exercise in the form of greater understanding, continuous improvement,
elegance of design, and re-readability of the code.

> Creating development infrastructure, tools, or automation that is only
> readily-understood by people who have had extensive experience with them

The reality of this matter is that running custom software, especially cloud
software, is tightly bound to infrastructure and operations, and there are no
absolute standards. There are popular tools--make, Maven, Jenkins, etc.--but
they serve to implement a very specific process. Even on a full lifecycle
stack like JavaEE that has specific parameters for deployment and management,
it's really not the whole story.

I'd rather have a development infrastructure that I can rely on and risk it
being a bit opaque than not have any.

------
shasta
Summary: Measure productivity as the time you spend working minus the time you
spend working on stuff that's not useful.

This definition of productivity doesn't even have the right units (time
belongs in the denominator, not the numerator), and the analysis in the blog
is muddled (why exactly does it matter whether or not I count lunch as 'non-
value-added' since I'm going to subtract it anyway?)

------
raganwald
To argue against this metric, I will use _Reductio Ad Absurdum_.

Look at the finished software. Count the characters in the source code. All of
the source code, tests, comments, configuration files, whitespace, everything
in the project's source.

Divide by five. That's the number of words. An average professional typist can
type at 50-70 wpm. we're professionals, so we'll take sixty. Divide the number
of words by sixty to get the number of minutes.

Perfect productivity for a professional-grade typist consists of spending that
number of minutes typing out the finished software. Take the number of minutes
actually logged by the entire team and divide by the perfect productivity
number.

If the team took twenty times as long, they have a productivity of 5%. If it
took 1,000 times as long, they have a productivity of 0.1%.

This is the same thing the author advocates, only I am suggesting that any
activity except typing code that appears in the finished product is what the
author calls a waste.

Something stinks here.

------
jonstjohn
This level of micro-management is something that can go a good ways to killing
a developer's energy and motivation. Micro-measuring productivity by writing
down the time that is diverted from productive tasks would be a nightmare.

------
xutopia
For something to be definitive it can be neither simple nor immutable.

