one road says, "(such as Active Time in Hackystat) would have similarly disastrous consequences were anyone to actually take them seriously" from The Mismeasurement of Science.
the other road says, "I’m finding that I actually like the time tracking. For one thing, it’s a tool for focus. When you kick off the timer on a task, you don’t want to jump around and multitask because it will just throw off the timer. The timer feature itself is pretty easy to use.” from Some feedback on EBS.
Two roads diverged in a wood, and I-- (robert frost)... and i... think its funny how systems like FogBugz and Bamboo are finally adding metrics to their systems.
FogBugz and Bamboo provide compelling arguments for their features. Just like 6th Sense Analytics. They look nice and make sense from a management point of view. However, I think what I've realized is that from a developer point of view these simple metrics doesn't really make me a better programmer. Don't get me wrong i think it is totally awesome to have those metrics to increase awareness and manage certain things. But, i want to jump to the next curve. I want systems that help me gather as many 10 second vignettes of knowledge as i can.
Hackystat has already done coverage reporting, timesheets, and automated time tracking. we've done those type of things. and i still think that metrics (as presented by the three previous links) has not improved my development one bit.
my software development has improved by debating with, communicating, learning from, teaching, pair programming with, yelling at, getting yelled at, blogging for, reading blogs of, emailing, and just working with great hackers. if you can package that up and bottle that, then you've got it! thats how you get 10x productivity and hit the high notes. if you can harness that relationships; improve the ability to share information along with metrics pointing you in the right direction, then you've hit gold. i've realized that context is always the number one thing. the context of the problem and the context of the solution.
thats the difference between the two roads....
2 comments:
Hackystat provides some communcation and development between developers. Remember Cedric's build failure predictor thing? Man that made me a better hacker. I was the first one that thing pointed out. Now I always make sure I run a complete build of the system, unit tests and all, to make sure that I've got a valid working copy.
This is more of an extreme case and I do agree with your point. We need to bring context with all of this data. This is not an easy problem. Just look where we are along the semantic web timeline (yes twitter pun intended)
good point austen. and i totally agree that integration of metrics in hackystat is our special sauce at this point.
build failure predictor thing was a support mechanism for managing your build process. in that sense, it did a great job of enforcing our practices. likewise, if our practices state that we should have X% coverage then hackystat (and the other tools) do a good job again.
what i'm going after is... a more intelligent system that says, coverage in this module is important. or taking it up a level, following a design pattern in this module is critical.
i like what philip said, "It
seems like we are tending naturally toward focussing on "being in the
moment" and trying to improve what we're doing right now, rather than
worrying about how we can better approximate some distant time and
place to be at." in my opinion, that is how we can revolutionize the use of metrics.
we should be focusing on improving our tasks and our low level developer skills. aggregate metrics and monitoring should be the "extra bonus". if we can do that, then we are golden.
Post a Comment