I was reading from "Good to Great", excellent book, and it mentioned one of the things successful companies did was chase a simple, single ratio. Sure, there's always more to it, but that one ratio helps focus the team. For most software departments, that ratio is something like:
(Requested Features / Incident Count ) per developer per month.
Basically, you want to crank out lots of features and have very low incidents. "Emergency" deploys, production bugs, outages – those essentially count as incidents.
All the good things either help increase requested features, or decrease incidents, and hence drive this ratio up.
Increase: Requested Features
|
Decrease: Incident Count
|
· Application frameworks
· Reusable blocks
· Code generation
· High quality, motivated, developers
· Tools
· etc…
|
· Automated build and deployment
· High unit testability
· Low QA bug count
· DevOps, application monitoring
· Developer conscience
· etc…
|
Most of the time, a team gets into trouble when it starts chasing things other than this ratio:
· Hours on a timesheet (instead of actually producing something)
· Face time in meetings or the office (instead of actually producing something)
· Thinking how their manager thinks (which may not actually increase feature output)
· High Lines-of-Code count (more codes != more features)
· "Feeling" busy (merely feeling busy doesn't mean cranking out useful code)
· Cool technology for the sake of cool technology
· Job security via undocumented process
· Coding to show how smart you are (as opposed to code to make the requested feature)
· Rating/grading the quality of developers (as opposed to making the business happy with working features)
· Avoiding mistakes (as opposed to the addition of value)
Sure, these things by themselves aren't bad (avoiding mistakes and using new technology), but they are secondary to the real goal. As long as a developer – or worse, an entire team – chases them instead of the real goal, they will always be less than great.
No comments:
Post a Comment