I'm currently scheduled for 2 sessions in the TechEd developer track for TechEd Aus (if I'm reading Andrew's
posting correctly), and if the logistics work out OK, I'll also be doing at least one of these sessions in Auckland as well. We have just wrapped up a release at CommBank, so I plan to use the lighter workload over the next week or so to get the sessions ready (rather than leave it to the night before like most speakers have an unfortunate tendnacy to do).
After a long break while I moved house, did a fair few .NET articles, and got settled back in with on-site work, the next long-awaited installment of The Trip.
And I think I did it with a single link. Frank's full list is
here. It just show's how many people are trying to get
Bluetooth ActiveSync working with i-Mates. Frank provides a great service by posting these detailed instructions.
BTW, after my initial set-up frustrations, the K-JAM has performed flawlessly. Getting through a ton of great MS Reader titles on the device, and it has performed great with good battery life and none of the device hangs I had with the Smartphone 2.
One of the most endearing (and at time frustrating) qualities of the software industry is out constant search for tools and methodologies to do our job better. In the spirit of this continual improvement mind-set, there was a discussion on the Stanski Australian dotnet mailing list a while back about estimates for a project. Neil Roodyn (www.roodyn.com), who is a globe-trotting author and consultant, suggested that the key to accurate estimating is breaking-down any task. Neil goes into further details here is his Extreme .NET book.
To quote Neil at length:
"Any problem that I estimate to take longer than four hours to solve is too big for me to feel comfortable with. I want to accomplish at least one thing in a day; if I accomplish more than that, I feel even better. This is a personal decision, but most people I have worked with aim for four hours or less. I have never worked with anyone who was comfortable with tasks that lasted more than six hours. If I get a task that I estimate will take longer than my maximum four-hour period, I break it down into several smaller tasks. If any of those tasks will take longer than four hours, I break those down again. Something that I have found interesting is that the most effective developers I know break down the majority of their tasks so that they require less than an hour to complete."
In a podcast, Neil says: "We can estimate how long it will take to do a 15 minute task very accurately. Estimating how long it will take to do a six week task is usually off"
This task break-down is meant to produce an estimation that is more accurate. From what I can figure out, this break-down serves two purposes - you are supposed to get better accuracy by estimating small tasks, and you are forced to think all the things that are needed to complete at task.
Breaking-it down assumes that uncertainties and inaccuracies in estimating large tasks become relatively smaller as the task gets smaller. I believe this assumption is absolutely flawed. Inaccuracies and uncertainties are proportionally similar to the task they relate to. To borrow a geometric term, they are fractal.
Fractals exist everywhere in nature - if you look at a coastline from space, from a plane, from a tall-building, or from a magnifying glass, the outline of the coastline exhibits a similar pattern. If you look at stock-market variations over a minute, a day or century, the patterns of ‘random’ variance never disappear.
If you ask a developer how long it will take to write a method, a class, an application or an enterprise system, the errors from failing to include things they need to do and the errors they have in estimating the time for the things they know they need to do will be proportionally similar, regardless of the magnitude of the task that the estimation is against.
I looked around the web for some hard data that could be analyzed to see if this fractal pattern could be picked up, but couldn't find anything useful. Does anyone know of a collection of data that describes a bunch of projects that use vary granularities of task estimation? I doubt such a thing exists just lying around somewhere. I don't think it would be valid to capture the data yourself if you where looking for a particular conclusion - there is too much of a risk of subconsciously skewing the data during collection to get the result you want.
If breaking it down doesn't given more accurate estimates, what is the answer? Despite my belief that it doesn't give you better estimates, break-it-down is a good way to give you ammunition and confidence in arguing your estimate is reasonable (if not correct) – maybe that’s some of the rational for Neil’s argument. I'm also a pretty big believer in spending a fair bit of time with clients/ bosses to understand their time and budget constraints, than doing what is possible code-wise in the time period. If your client/ boss is reasonable with their time and you are reasonable with your production, things tend to work out. This practice obviously has scalability problems when you get dozens and hundreds of developers involved. I'm not sure anyone has the ability to accurately estimate software when large teams and big legacy systems are involved.
Note that this post isn't meant to rubbish Neil - I have plenty of respect for him, and intend this to be part of an ongoing dialog that him and I tend to have over a variety of mediums regarding various XP principles. Neil is a good guy, and his book is worth a read.