|
|
|
|
|
|
by slantyyz
5811 days ago
|
|
|
Reading his points, I wonder how much experience he has and what the scope of his experience is. My experience is that if you've got multidisciplinary teams populated with reasonable people who have a good grasp on real world constraints (usually a delicate balance of compromises between scope, quality, time and money), all of his four points break down. On the measurement point: While I'm sure some of the more clueless companies might use some arcane and pointless measurement systems, I haven't seen any half-decent dev shop use any of the measurement practices he talks of. |
|
|
Really, we need some kind of measurements or metrics. Otherwise, how else do we know we're progressing or improving or at least not sucking more.
I agree that metrics is hard to do and easy to game. That's why don't put a specific number or targets. And also don't tight metrics with employee performance. Put it on team's performance (still not perfect, but I'm sure it's better).
One example of metric that probably might have made sense is that if your shop is doing Agile (code review, code coverage, unit-test, # of bugs etc.) is to make sure that these numbers don't go down in every iteration. Make sure these numbers either stay the same or go up (in the case of improvements or new development). If the numbers go down for 2 consecutive iteration, someone or some team doesn't care about quality. Track improvements, not specific number.
Side note: I would suggest people to read Standish Group Chaos Report to understand how bad our industry was and how far have we improved over the years.