JLOFT: Estimating with Eiffel

I have been both a W-2 employee and a free-lance contract software engineer. My contracting days lasted about 10 years (more or less). During that time, I began to see a reality happening for me repeatedly. It led me to adopt an outlook on estimating software projects: "Take whatever time you think it will take to complete a task and multiply it by three or four and you're probably closer to the reality of the actual completion time." This little thought has both helped me and hurt me, but it has proven (in my world) to be a fair estimation.

Fast forward from the past to JLOFT-present ...

Yesterday, our team was planning our next sprint. We poured over the product backlog task list, placing items into the sprint and then started assigning estimates of hours. Three items in particular stood out as grossly underestimated. We initially assigned 2 hours each to them. On reflection (e.g. a second pass through the list), we challenged ourselves to "think again" about those 2 hour estimates. In the end, each one became 8 hours instead of 2 and blossomed what originally appeared to be a half-day of work into 3 full days.

One of the smaller tasks on the list had been performed by one of our juniors. When we first asked him about it in the meeting, he was sure the matter would only take about 20 minutes to handle. However, the majority of the team felt differently and we raised the estimate to 2 hours. Again -- a 20-30 minute (half hour) job was multiplied by 3 or 4. As it turns out, we actually started the sprint yesterday at about 3 in the afternoon. At the end of the day, the job that appeared to our junior to be 20 minutes did (in fact) take 2 hours. An additional task of about 30 minutes rounded out the day and we ended-off the day at about 5:30 PM.

So -- how does Eiffel fit into this?

Eiffel is not a fix or silver bullet to the human mind and the perceptions of our biological mental mechanics. As good and as elegant as Eiffel is, when it comes to estimation of work, the unknowns of software engineering still apply.

I arrived in Atlanta in the fall of 2005. A fellow I met at that time shared a nugget with me that has proven true over and over again: "Whatever you focus on expands!" Few things I have ever heard have been so loaded with deeply pragmatic truth. Software engineering is certainly well represented in application of this little saying.

In our planning meeting, we chose to not simply take our first-blush estimates and rely on them, but we gave a little more focus. The result of focus was the expansion of detail. I sat in comfortable amazement to watch even seasoned engineers as the process of focus-and-expansion took over, details blossomed and time estimates grew.

What Eiffel is bringing to our table is not faster estimates of completion but of software that is more appropriately constructed -- its quality factors and robustness raised -- to the end that our true gain is in the arena of maintenance.

For Eiffel people, this is not new news. I suppose my purpose in blogging about this is to capture the experience of how software engineering as a reality-based enterprise continues on unabated even in an Eiffel world. Said another way -- some realities simply cannot be escaped or remedied because they exist as a consequence of our mental mechanics and the world around us.