3 ms·

What would those metrics be, though? Pretty much every metric anyone has ever come up with to "measure" software development has been worthless, and it doesn't

by akeefer 17y ago

What would those metrics be, though? Pretty much every metric anyone has ever come up with to "measure" software development has been worthless, and it doesn't look like that trend is going to be broken soon. It's like trying to apply metrics to writing a novel. After a certain point, if something doesn't work you have to accept that maybe it's just a bad idea, and I think we're well past that point with software development and metrics. About the only useful metrics I know of are all end-state sorts of things: bug counts and regression rates, number of satisfied users versus dissatisfied users, number of successful implementation projects versus failed implementations, and whether you can generate real revenue or business value. As soon as you start trying to look at things like number of lines of code, "function points" implemented, coupling metrics, test coverage metrics, etc. it tends to start distorting your development efforts, and the harder you push on formalisms and hard metrics the worse it gets. Pretty much any metric in software is really a way to get at some unmeasurable underlying thing like "quality" or "rate of progress," but they're always easily gamed. It's like standardized tests and education: the more you push on "accountability" and standardized test scores, the more teachers teach strictly to the test, and the less the kids actually learn. Similarly, of the best ways to destroy a software project is to guide the development based on metrics. I think you get much better results if you approach software as a design process, which is inherently unpredictable and non-repeatable, instead of as a manufacturing process where predictability and repeatability are the desired goals. As much as the word "agile" has come to be almost meaningless these days, that's really the original insight behind it: on a fundamental level, software development is an unpredictable, non-repeatable design process, and so the best you can do is to expect that to happen and build in ways to deal with that, rather than instead trying to exert more control.

shpxnvz 17y ago
It's like trying to apply metrics to writing a novel. Oh, that's not hard to do. The only one that matters in the marketplace for software is the same one that matters to most novel publishers - does it make money. That's a simple metric to measure and it's one that corporations instinctively understand, both in software and in novel publishing. Monetarily successful software publishers, just like novel publishers, know very well what the quality sensitivity of their customer is, and produce accordingly. The metric (and the audience quality sensitivity) is obviously quite different when you are talking about niche product, be it aircraft control software or a mathematics textbook.

by akeefer 17y ago

shpxnvz 17y ago

It's like trying to apply metrics to writing a novel. Oh, that's not hard to do. The only one that matters in the marketplace for software is the same one that matters to most novel publishers - does it make money. That's a simple metric to measure and it's one that corporations instinctively understand, both in software and in novel publishing. Monetarily successful software publishers, just like novel publishers, know very well what the quality sensitivity of their customer is, and produce accordingly. The metric (and the audience quality sensitivity) is obviously quite different when you are talking about niche product, be it aircraft control software or a mathematics textbook.