Contents tagged with goals2004_Metrics
-
Re-useable harness for tray-based applications
Today I started writing a new little hobby application / productivity tool which I'm planning to implement as tray application. The first thing that I did was to crack open the code from Duncan's 3rd Coding For Fun article titled: "Checking My Email"
-
Terrarium : Some data about saving energy
As I mentioned in my last post, it's important to conserve energy in the Terrarium game. So, if you are moving - maybe looking for your next meal - and are not under any threat of attack, it is wise to meander along rather than sprint. Likewise, it is much better writing code which allows you to avoid being attacked as opposed to running away from a fight.
-
String::Split - unexpected behaviour?
After a comment which was left by Justin Rogers on a recent post of mine I decided to do a bit more testing to confirm the behaviour of String::Split. The documentation has this to say about it:
-
More timing, different types of tests
Yesterday I blog'ged about some various string splitting times. One thing which amazed me was how slow the VB Split Function was:
-
Timing Split; getting a handle on things.
Tonight I decided that, before I attempt to match the speed of Split, I'd better measure it out to see how fast it is. Here's the results of some simple tests...
-
WordWrap. Faster than Split?
At lunchtime today I was discussing my WordWrap component with a fellow developer which - of course - led us into discussions as to the merit of the task and also how "optimal" we could make the underlying "wrapping" algorithm. When I started talking about my current algorithm we discovered that I'm doing several
Split's and then speculated as to what the faster algorithm might be. We decided that it would be good to benchmark our final wrapping algorithm against the time it takes to perform a singleSplit()operation against the same input. It will be interesting to see how close we can get toSplit()time. -
Changing the metrics categories
OK, one day into it and I'm already making changes. My new categories for recording development time are:
-
What my metrics will and will not tell me.
So, today I started out on my path to statistical verification. My first job was to grab a small, pocket-sized notebook to keep track of my daily entries. The notebook will be kept in my pocket at work so that I can easily make entries as they are required. The idea of using paper - as opposed to some sort of technological wizardry - was forwarded by Darrell Norton who seems to be a fountain of useful information when it comes to process improvement ideas and the like... thanks Darrell!
-
Measuring development activities should be easy - not hard.
Yesterday's discussion on "developer metrics" seemed to be a bit of a curve-ball and I received some mixed feedback. I think that one thing which threw people was when I mentioned the deadly phrase: "Counting Lines of Code" { insert sinister sound effect }. It's a bad metric and should be removed from my original posting unless (of course) you have a tool which is sophisticated enough to provide a reliable and meaningful count of lines (i.e.: working lines, raw lines, checked-in lines etc.) -- and I don't! And nor do any of the programmers that I know, so I'm gunna chuck that measurement out (for now).
-
Lies, damned lies and statistics
The other day whilst reading some of ^Z's entries it struck me that he uses metrics to mark many of his important observations. This is a hallmark of many of my trusted sources of information. For example Mark has been keeping a log-book of his jogging; he can now look back through the statistics that he's been keeping and use them to check his jogging patterns. I think that this is important because - as I've mentioned previously - it's often easier to plan for where you are going if you know where you're coming from.