|
|
Re: Software Metrics Don't Kill Projects, Moronic Managers Kill Projects
|
Posted: Nov 6, 2007 2:53 AM
|
|
> Your argument - and please correct me if I paraphrase it
> incorrectly - is that metrics such as CRAP oversimplify to
> such an extent that the metric number by itself carries
> no actionable information at the 'manager level'.
> Since it takes a developer to go and look at the details
> s before deciding if any justifiable action should be
> taken, the metric should not be reported above the
> developer level.
Yes indeed. That's a very good summation of my argument.
> If that's the case, I believe we are more in agreement
> than you think. I agree that a metric such as CRAP is
> much more useful to, and actionable by, developers
> than managers. CRAP is actually meant to be used
> primarily by developers (hence the IDE plug-in). I also
> agree that, in mapping the code into a single digit there
> is an unavoidable loss of information.
You're right. We broadly agree about the tool, what it does and how it can be used by a developer.
> But I don't agree
> that such a number does not provide any useful
> information to a manager. As a matter of fact, I don't
> think you believe something that black-and-white (i.e.
> that it's completely useless) either, because you say:
>
> >...but the fact is that the original metric
> >is just a flag...
Yes, here is the nub of our disagreement. I've just delivered a small application as part of a two man development team, reporting to a team leader and thence - as required - to various managers (the development/delivery manager, the manager of the maintenance team that will be looking after the code into the future and, not neast, the manager of the people that will be using the code (oh and the intranet manager that will be hosting the code)).
In all these cases, none of these managers have any interest in the source code nor any particular property of that code. They do, however, want to know that the code works, is compatable with existing systems, is written in a company approved language/framework that the maintenance team are familiar with, is in the company CVS repository.
To be assured on these fronts, all the managers delegate getting assurance on all these questions to their teams and those team members come (at various stages of the project) and eyeball what we're delivering (UI, system interfaces or code, as appropriate). Those people may (potentially) look also at metrics, but - to date - none has. They will then report back to their managers on whether or not our code is fit for purpose but it's unlikely that the report would carry specific metrics on the source code. (Well that's not entirely true. They do seem to have an unnatural preoccupation with code 'volume' here, e.g. "Application X takes up 3.56Mb of disk space on the server", etc.)
> I think I see an opportunity for reaching some sort of
> agreement because a 'flag' is not completely useless.
OK, agreed that it's "not completely useless" for managers(provided you agree that that's a synonym of "not very useful"). :)
> I
> need to do some a lot more thinking about it, but I am
> willing to explore the possibility that metric may
> be too strong a word for most things we call metrics.
> Perhaps they are just flags; warning signs, binary
> indicators that something is potentially wrong and
> d that someone should go take a closer look.
>
> Are we moving closer Vincent?
In all likelihood. I think the problem is not so much in the mechanics of generating a metric (where you appear to be well grounded) but in determining just what exactly is the best way to "summarise" a block of code, what it is that needs to be said about the code (and to whom) and how much or how little informationneeds to be provided.
|
|
Previous Topic
