A recent post on ZenHabits entitled Toss Productivity Out has piqued my interest. The title says the post is about productivity but a lot of the content strikes me as a comment on the benefits of understanding your priorities. Understanding and focusing on priorities simplifies your life.

Take the simplification argument used against getting organized. If you simplify you are effectively making choices on importance. If not then you introduce complexity into your life. Simplification forces you to prioritize. If you focus your priorities life becomes simpler.

The same argument can be made on the number of goals you set. And again for focusing on a couple of things to be done during the day instead of keeping detailed context lists.

The post makes other points against productivity methods. These look like an argument against selecting productivity methods that don't help you identify what's important.

In all, the important message is about managing priorities and about selecting ways that support the identification of your priorities. Evaluating your productivity methods in light of how they help you determine your highest priorities and then focusing on them is a great way to simplify.

I am re-reading Mike Cohn's book "Agile Estimating and Planning". It's turning into a good opportunity to take a second look at the references. In chapter two, "Why Planning Fails", Mike references an article by Phillip Armour "Ten Unmyths of Project Estimation" published in the November 2002 issue of  Communications of the ACM.

Mike's main point for referencing the article is to link the idea that an estimate represents a probability of completing a project. It often becomes a commitment to an end date. I view this as a variation of the idea presented in chapter one "The Purpose of Planning" and what the concept of the cone of uncertainty teaches us.  The two reenforce the point that estimates are not 100% accurate.

If you are not familiar with Phillip's article I encourage you to read it. A couple of unmyths that I particularly enjoyed.

• The accurate estimate myth. Funny that people forget what an estimate really is!
• The lines of code myth. Hilliarious that people actually measure this to capture productivity!

I like the idea that the cost of software is associated with knowledge acquisition. Since people learn at a finite pace adding more people to a project doesn't make it faster and has the downside of parcelling
out the knowledge into smaller pieces so that no one really has the whole picture.

The main point of Phillip's article is that estimates are highly educated guesses. They are not exact and that is why it's called an estimate. This point drives home the fact that the only way to improve the probability of an estimate it to continually revise the estimate based upon new knowledge and information.

If that knowledge and information is used by expert estimators then you remain within the cone of uncertainty and are provided a higher level of assurance that the project is under control.

I've noticed a trend in my reading of David Moody's books. In both the Autumn and the Hater series I enjoyed the second book more than the first. This isn't to say that I didn't enjoy the first book in each series, just that the second books were better. This might be a good sign as Hater is a trilogy and there are five or six books in the Autumn series.


With the Hater series, I read Dog Blood first and then moved to Hater to get the background. Dog Blood was sufficiently different from other stories that I've read it was able to keep my interest without having read Hater. In the end, I read Hater for the background it provided on some of the characters in Dog Blood and because I enjoyed Dog Blood so much. It is worthwhile pointing out that Hater can stand on its own even if its not the first book that you read in the series.

I started reading at the beginning of the Autumn series. Autumn is a good story and Autumn: the city is a better story. The second book tells the story of a different group of survivors. There is similarity between both books but enough difference to justify reading each of them. I think the most striking difference between Autumn and Autumn: the City is that the beginning of Autumn is so abrupt. Almost everyone dies in the first few pages and the rest of the story is about coming to terms with what happened and surviving the aftermath.

Autumn: the city has a similar beginning but there is a significant difference that improves the story line. This difference is the focus on the reactions of the survivors in Autumn: the City and the changes to the dead seem to happen sooner in the story line.

All in all, I like all four books. In terms of ranking them I the following order is appropriate.

1. Dog Blood
2. Autumn
3. Autumn: the City
4. Hater

I have been re-reading Mike Cohn's book "Agile Estimating and Planning" in an effort to deepen my understanding of Agile practices for estimating software. The first chapter, "The Purpose of Planning" introduces the cone of uncertainty to discuss software estimates and provide data on the accuracy of estimates over the various phases of a project.

I was intrigued because the cone and the approach used by the PMI are different—the cone views estimate accuracy as symmetric with initial estimates of ±4 times the actual cost of delivering a project. The PMI views initial estimates as asymmetric and places these estimates at +75% through -25% of accuracy.

Some research on the cone lead to insights that weren't clear from reading chapter one. The most important is that the cone of uncertainty represents the best you can do when estimating software. It says nothing about how bad you can do.

A good resource is Brad Appleton's blog post on The Cone of Uncertainty. This is an old post from 2006. Of the links provided with this post the following are still live and useful.

Coding Horror says:

An important--and difficult--concept is that The Cone of Uncertainty represents the best-case accuracy that is possible to have in software estimates at different points in a project. It is easily possible to do worse. It isn't possible to be more accurate; it's only possible to be more lucky.

Best case estimates are created by expert estimators. Worse case estimates are not considered. Furthermore, you must be diligent in improving and reassessing your estimates otherwise your cone of uncertainty becomes a cloud. The cloud of uncertainty is characterized as that notion of being 99% of the way through a project and having been there for a long time.

Construx says:

If you’re working on a project that does a full development cycle each iteration—that is, requirements definition through release—then you’ll go through a miniature Cone on each iteration. Before you do the requirements work for the iteration, you’ll be at the “Approved Product Definition” part of the Cone, subject to 4x variability from high to low estimates. With short iterations (less than a month), you can move from “Approved Product Definition” to “Requirements Complete” and “User Interface Design Complete” in a few days, reducing your variability from 4x to 1.6x. If your schedule is fixed, the 1.6x variability will apply to the specific features you can deliver in the time available rather than to the effort or schedule. 

You have to go through a full development cycle for each iteration. Doing so can reduce estimate variability from 4x to 1.6x. For a fixed schedule that 1.6x variability applies to features that can be delivered in the time available rather than effort or schedule.

Most teams reach a compromise and establish most of the requirements up front. They use iterations to tackle the other phases of the projects. This approach tends to reduce the variability of estimates to ±25%.

I think it important to emphasize the cone only shows the best accuracy you can achieve, even with expert estimators and only if they continually reassess their estimates as the project progresses. Worse case estimates can always be much worse than what is shown by the cone.

I have been struggling with the decision on whether to purchase an iPad or not. Initially, I choose not to be an early adopter. That was easy as all I had to do was decide delay the purchase. Over a year has come and gone and I've learned a lot about what I'd like to do with an iPad if I were to purchase one. Ultimately, I determined that I would keep my laptop and not purchase an iPad.

My rationale for not purchasing an iPad comes down to two simple facts. First, not everything I want to use on my laptop is available on the iPad. Second, I don't need another device to carry around. I already have a MacBook and an iPhone. The thought of carrying a third device or having to make a decision on whether to take the laptop or iPad with me is not worth the effort.

I view the iPad as ideal for people who only want to surf and read email. I include in surfing, things like reading books and documents on the iPad. I won't replace the books I read simply because I am a little old fashioned and like my books made of paper. Surfing and email are the only things I do on an iPhone that I find inconvenient. These activities could be improved with the purchase of an iPad but the cost doesn't justify eliminating my personal inconvenience with these activities.

One iPad feature that took a lot of thinking to eliminate was the 3G option. I ultimately decided to forgo that since the iPhone now supports local WiFi though the personal hotspot feature. That and the fact that the cost of the 3G data plan coupled with the small data transfer sizes provided by Canadian carriers are patiently ridiculous.

In all, I won't be purchasing an iPad for myself because the two devices I already own more than meet my needs. I may still be ogling the iPad every time I drop by the Apple store or their web site but I don't think I'll be laying any cash down for the device itself.