3 ms·

"The use of easy-to-obtain metrics with little or no predictive value has interesting parallels in all sorts of places." I was just wondering if there were par

"The use of easy-to-obtain metrics with little or no predictive value has interesting parallels in all sorts of places." I was just wondering if there were parallels for this in programming. The obvious might be the various approaches and "methodologies" to programmer or team productivity based on dubious or non-existent hard data. But I'm more wondering if there are tools or techniques that don't get any accolades (like, say, MVC or TDD or the framework of the week) but have a peculiar synergistic effect that ends up providing significant (and possibly counterintuitive) value. What's the "Shane Battier" of software development practices? And how would you know?

pmccool 17y ago
I definitely think there are parallels in programming. The lines of code metric comes to mind.
pook 17y ago
Larry Osterman's "MEASURING TESTERS BY TEST METRICS DOESN'T" essay has some good bits on where metrics give perversely wrong conclusions. http://blogs.msdn.com/larryosterman/archive/2004/04/20/116998.aspx http://blogs.msdn.com/larryosterman/archive/2004/04/20/11699...
InclinedPlane 17y ago
I'd say good design. Refactoring has known benefits, but good design is similar to refactoring while skipping the middle step of having a cruddy design to start with. Developers who tend to write better designed code may not be appreciated for it. Consider that better design often requires considerable forethought and may take longer to implement than a typical "first thing that comes to mind" satisficing type design. Also, the lack of future bugs and lack of future difficulty in expanding and adapting good code may result in a lack of attention for that code (people may not appreciate its subtlety and elegance and merely think it solves an easy problem to start with). The end result may be that the developer takes longer to resolve fewer bugs and implement fewer bits of functionality than other developers while the benefits of higher quality design and code might be largely invisible. Discerning developers may be able to recognize and appreciate higher quality coders, but in environments with short-sighted or overly bureaucratic management I'm sure this sort of problem exists.
- pmccool 17y ago
  Trouble is, "good design" is pretty hard to quantify. It's much much harder to quantify than things like LOC, or whether this milestone or that was reached. Another difference is that a basketball game has a definite, qualitative outcome. That, at least, can be measured. With software development you don't even have that luxury.
  - eru 17y ago
    Did you mean, "a definite, [quantitative] outcome"?
    - pmccool 17y ago
      Yes. Oops.
  - InclinedPlane 17y ago
    Quite so, there's no objective measure for good software, other than perhaps sales (and it's enormously difficult to trace sales data back to individual contributions from one out of dozens, hundreds, or thousands of devs). Which is why software development is still very much a craft. And a pretty esoteric one at that. It often takes the subjective judgment of a known good developer to determine the quality of another developer's contribution. The unfortunate side effect of this is that the really good dev shops (populated by talented devs even in management roles) are working at levels many, many orders of magnitude beyond what the run of the mill dev shops are capable of. There are a great many development projects managed or overseen by non-developers, and many of those people lack the basic skills necessary to tell the difference between gold and utter crap. It's no surprise then that so much "enterprise-y" development is little more than snake oil, VBA scripts and MS access duct taped together and sold for millions of dollars to big companies who don't have the skills to know they got taken for a ride. Software development is only just barely scratching its way out of its alchemy and astrology phase. There are far more untalented, unskilled hacks out there than there are honest craftsmen.

pmccool 17y ago

I definitely think there are parallels in programming. The lines of code metric comes to mind.

pook 17y ago

Larry Osterman's "MEASURING TESTERS BY TEST METRICS DOESN'T" essay has some good bits on where metrics give perversely wrong conclusions. http://blogs.msdn.com/larryosterman/archive/2004/04/20/116998.aspx http://blogs.msdn.com/larryosterman/archive/2004/04/20/11699...

InclinedPlane 17y ago

I'd say good design. Refactoring has known benefits, but good design is similar to refactoring while skipping the middle step of having a cruddy design to start with. Developers who tend to write better designed code may not be appreciated for it. Consider that better design often requires considerable forethought and may take longer to implement than a typical "first thing that comes to mind" satisficing type design. Also, the lack of future bugs and lack of future difficulty in expanding and adapting good code may result in a lack of attention for that code (people may not appreciate its subtlety and elegance and merely think it solves an easy problem to start with). The end result may be that the developer takes longer to resolve fewer bugs and implement fewer bits of functionality than other developers while the benefits of higher quality design and code might be largely invisible. Discerning developers may be able to recognize and appreciate higher quality coders, but in environments with short-sighted or overly bureaucratic management I'm sure this sort of problem exists.

pmccool 17y ago
Trouble is, "good design" is pretty hard to quantify. It's much much harder to quantify than things like LOC, or whether this milestone or that was reached. Another difference is that a basketball game has a definite, qualitative outcome. That, at least, can be measured. With software development you don't even have that luxury.
- eru 17y ago
  Did you mean, "a definite, [quantitative] outcome"?
  - pmccool 17y ago
    Yes. Oops.
- InclinedPlane 17y ago
  Quite so, there's no objective measure for good software, other than perhaps sales (and it's enormously difficult to trace sales data back to individual contributions from one out of dozens, hundreds, or thousands of devs). Which is why software development is still very much a craft. And a pretty esoteric one at that. It often takes the subjective judgment of a known good developer to determine the quality of another developer's contribution. The unfortunate side effect of this is that the really good dev shops (populated by talented devs even in management roles) are working at levels many, many orders of magnitude beyond what the run of the mill dev shops are capable of. There are a great many development projects managed or overseen by non-developers, and many of those people lack the basic skills necessary to tell the difference between gold and utter crap. It's no surprise then that so much "enterprise-y" development is little more than snake oil, VBA scripts and MS access duct taped together and sold for millions of dollars to big companies who don't have the skills to know they got taken for a ride. Software development is only just barely scratching its way out of its alchemy and astrology phase. There are far more untalented, unskilled hacks out there than there are honest craftsmen.