The use of analogies when discussing software development is quite common and has rung true with #NoEstimates. We know that an analogy is a construct of our languages that allows us to explain “a thing” by using something else that is similar and familiar.
In the case of #NoEstimates, analogies have used activities such as building a house or fixing a car. The point being that the individual who wants these activities performed for them needs to know the cost upfront. So while these analogies may be good, I still have a problem with them (and yes I understand that no analogy is perfect) for the simple fact that (a) my experience informs me that the nature of these activities is different enough from that of developing software and (b) I think there are better analogies.
Before my mechanic fixes my car, he performs a thorough assessment of the vehicle until he determines what the problem is and how it is going to be addressed and then he provides the cost (it’s not really an estimate). When I had my basement finished, it was also a very similar process of defining upfront what was going to be done and how it was going to be done and then getting the quote. Don’t get me wrong, we can approach software development in exactly the same way we approach fixing a car or building a house. We can try to get to that level of detail upfront and in some cases, maybe its the right thing to do. But with all the knowledge and experience we now have, is this what our general practice should be?
In my experience, non-software people (the people we like to call the “business”) already consider software development to be just like building a bridge, finishing a basement or repairing a car and use the same analogies we use (or taught them). When we (re)use the same analogies, we validate and reinforce their thoughts and ideas. In my experience, this is rarely helpful. I prefer to use analogies that highlight the continuous discovery, learning and experimentation that occurs during software development that I am involved with such as that of developing a recipe (food), a pharmaceutical drug or new school curriculum.
At the heart of this is the debate regarding the nature of the work we do. Everyone is largely influenced by their own experience. If your experience is like that of building a house or fixing car, then using those analogies might be the best you can do. If on the other hand, your experiences are like mine, then try to use analogies that highlight the fact that we will be learning (a lot) as we go along. I think it will benefit everyone involved.