Many people read this great paper, but a lot of them are still hoping to find the magic tool, the miraculous methodology, the final language that will allows them to manage complexity with minimal effort.

Agile development, OOP, Design Patterns, JAVA, VB.NET, UML are all great tools, really, but they were never designed to be silver bullets. The problem is, some people (at least one in every company ) just buy a new tool or dive into a new technology, a new methodology, a new language, hoping that they will get a 50 % productivity improvement.

This is a real problem and it seems to be as old as software development. In fact, this attitude just leads to opposite results.

We have to tell them again and again and again : no, there is no Silver Bullet – you want something great ? It will not be cheap.

Particularly with approaches like an agile approach to process, but also others, people often find themselves in a “first step” paralysis mode. They have a broad feeling for what they’re looking to be doing, they’ve grokked the wider principles behind the approach, but they’re feeling around for where to start. I’ve experienced this feeling in many areas of life, and it’s disconcerting (I don’t think that’s particularly an admission of my idiocy, though I’m not ruling it out).

I think what a lot of people are looking for the stabilisers, that a tool might provide. Sitting down with a blank sheet of paper is more daunting than sitting in front of a piece of software which starts asking you questions. Even a text box with “estimated story points here:” gives you a nudge.

When people are still looking round for tools, it may be that they’re foolishly searching for a magic bullet. It may also be that the guidance, community, etc. for what they’re trying to do hasn’t really yet provided much of a path to get started. This is probably particularly keenly felt with approaches such as agile, which almost eschew a “one true way” by definition.

Estimating is hard. If we want people to be able to solve those human problems (and I agree, they are) then maybe we need to look at making the problem more approachable in light of the weaknesses of human endeavor. Perhaps starting with a prescriptive approach (though it may not be the right one – you will find it later) is better than starting with a “find your own path” approach.

Just ramblings anyway.

“No tool can solve all your problems, especially if they are people problems. Good tools can help reduce friction in an organization, and possibly save you some time.”

or more succinctly

“No tool is going to make it easier to work with jerks”

Funny and thought-provoking post (especially the tool you recommend)!

In a long ago former-life, I worked as a mediocre lawyer at a good law firm. This post and the comments to it take me back to law school where, more than once, I would read one judge’s opinion on a case, think “Wow, great points; he’s right” only to read the dissenting opinion on the case and think “Man, brilliant points; he must be right too… hmmm, waitaminnute.”

Same theme here: I agree with all three of you to some extent.

Kudos to Mark for highlighting the other real issue of toolphobia. There are lots of good testing aides out there including, IMHO, our Hexawise test design tool. Using good tools is – on balance – a GOOD thing, provided, of course that testers can avoid the temptation to check their brain at the door and assume that if they “follow the tool” that their job will be taken care of for them. Great testing requires great testers; tools – used sensibly (as opposed to slavishly) – have the potential to help speed up certain processes, optimize other processes, and encourage collaboration between team members.

A few minutes before reading your post here, I sent out a tweet highlighting his very insightful and very amusing blog post that he referenced above… “@Hexawise RT @michaelboltonJust published: Test Estimation is Really Negotiation http://bit.ly/2nSP1i #softwaretesting #testing #qa Me: Amusing & good” It is definitely worth a read; it is no less amusing than your post and his recommended approaches to the estimation problem are, I suspect, more likely to be successfully implemented with good results than your admirably bold recommendation. Having said that, I would be willing to pay good money to participate with a testing team that used your “recommended” tool for estimation and saw the testing cycle out to the end using its results….

- Justin Hunter
Founder of Hexawise

My reply to the original problem is here (http://www.developsense.com/2009/08/test-estimation-is-really-negotiation.html) and here (http://www.developsense.com/2007/01/test-project-estimation-rapid-way.html). It involves no tools; just the human arts of negotiating and using heuristics to deal with uncertain situations.

—Michael B.