"Gutless Estimating" - Excerpts from "The Mythical Man-Month"

The following is a excerpt from the classic book "The Mythical Man-Month".
Read on the following paragraph carefully. Sit back, close your eyes and think for the next 2 minutes. Frederick P. Brooks, Jr. the "father of the IBM System/360," has written these lines 20 years ago. So little has changed over these 20 years...

Gutless Estimating

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices—wait or eat it raw. Software customers have had the same choices.

The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another.

Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.

Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data.

Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.

An universal format for resume

My most of the latter half of last week went into scanning resumes for a test automation position. HR in its part had dumped into a MS Outlook folder, quite a few resumes from internet job postings and candidates applied for the job posting on our company website. Given the enormous amount of work it takes to scan through the resumes for the right set of skill set and experience, I'm wondering if its high time the software industry propose an universal format for resumes.

Automated tools could scan the machine readable formats and save the drudgery of reading through pages text to get simple information like years of experience and skill set. This had prompted me to looked into wikipedia for a definition of resume. One format that had caught my attention was the hResume . Any new initiative requires big names to support it. Its time for the big companies to support a common initiative. The smaller one will follow suit.

Two Blogger bugs

After having started blogging, I've started looking at everyday things more critically. I noticed two things with blogger.com that caught my attention.

I have this habit of creating a blog post and saving it as draft. After many a iterations of writing and rewriting, I finally publish the post. Often times the gap between creating the post for the first time and publishing it takes several days. I have several draft post that I work on at any given point in time.

I created a post on February 26th, finally published this post on march 4th. The published date on my blog still lists as february 26th instead of march 4th.

The other bug related to my blog title, I'll still drafting.

Bug tracking system as risk management tool

As testing organizations within a company mature, the most noteworthy process and tool that stands out is the bug tracking tool. It’s only next to the project plan in reporting the "project health". Often times the bug tracking tool is used beyond its intended use of tracking bugs. In this post, (and few of the subsequent posts) I intend to describe few of these "out of the box" usages of the bug tracking system that I've seen being used in companies I've worked for. There was an incident few years ago in my company that resulted in using the defect tracking system for tracking ‘testing Risk’. This was a new release of one of key solutions for one of our banking clients. The developers had deferred many of the significant defects to later releases because of “time pressures”. Obviously there was resistance from the testers, but as always, developers could get their way out. Once the product went to the customer, these defects turned into “significant errors and show stoppers” and these issues escalated to the highest level.
The key lesson learned from this fiasco was the testing risks often go unnoticed without an escalation mechanism beyond the project manager. The proposed solution for this problem was to track the testing risk through the bug tracking system. Proximity of the bug tracking system to the testers and developers , the "reporting features" provided by the tool as well as its inherent feature to "track" ( from opening to closure ) resulted in the bug tracking system to be the first choice.
This is how the process is followed in our organization. Every project will have a defect component for “testing risk” created in the bug tracking system. Any bug logged against this component is treated as a testing risk.
Senior management monitors this “testing risk” component on a periodic basis. The most significant benefit we’ve achieved by following this process is to bring in an early warning system into the project.
My testing risks include “Late delivery of a feature “xxxx” leaves testing group little time to test it” , “Installer of the product do not work!” , “Performance tests on the product may be inadequate” and the list goes on…

The very first post

It’s been about two months now since I’ve been a following blogs very closely. My interest in blogs really developed until I came across two things. One is Google reader. Until google reader, I had not really come across any RSS aggregator that neatly classifies and displays the blogs you follow. Of course there are lots of other aggregator on the web, but nothing that does it as neatly as Google reader. And of course, google is the once place on the web you visit the most.
I’ve never had the though of having a blog of my own until I came across this inspiring post from Pradeep Soundrarajan. There are 4 type of blog enthusiasts. One who reads blogs but never owns one nor do not comments on others blogs, the “passive ones”. Second who reads and comments on others blogs but never own one. Third, the ones who reads others blogs, comments on others blogs and owns a blog. Over the past several months I’ve graduated to be on the third level. Of course there’s a fourth type of bloggers, who apart being a blogger of type three, receives several comments from other blog readers and are in the blogrolls of several bloggers.