In this article, part of my series explaining better ROI from software development, I’d like to look at the pros and cons of an analogy.
Software Development is complex. The problems it solves will always have a level of complexity.
As humans, we love stories – so it’s common for us to use analogies when discussing a complex issues.
Analogies can be a wonderful tool in bridging the technical divide – but can also lead to loss of meaning if over relied on.
As I’ve said before, Software Development is a complex business. It’s still fairly young in its practices and applications – and it is constantly changing (see ROI of Complexity).
It is a deeply technical subject, which uses its own (growing) lexicon of terms and meaning. I’ve been at this for over 20 years and still learning.
So why would I expect someone from the business without that knowledge to converse with me in my terms?
I wouldn’t … it simply isn’t fair on either of us.
Michel Thomas (world renowned language coach) tells us in his courses that in a conversation we are attempting to get our meaning “over the net” to the other party. Anything that doesn’t make it over is considered to be lost meaning in the conversation.
When I get truly technical, I might as well be speaking another language.
Using the time honoured method of storytelling helps to bridge that gap. Thus the use of analogies from which I can expect us both to have a shared understanding on which to base out conversation.
By improving the understanding of our conversation, I’m increasing the likelihood that we are going to arrive at a correct solution - thus being more efficient - thus improving ROI.
Unfortunately, while analogies can be beneficial, they can also have a dark malevolent side.
Sometimes one party can buy into the analogy too far – making assumptions based on that analogy, to which there is no correlation with the conversation.
No analogy will be 100% correct.
One common analogy is comparing a Software Development project to building a house.
Now this analogy is deep with potential benefits. Barring significant cultural differences, you can assume a good amount of shared understanding when it comes to house building.
There are some great analogies that can be drawn from building a house.
We can have comparable roles for example.
If Software Development, we can have a variety of “trades” similar to construction – all of which work together to produce the finished article. We even borrow some of the names and terms such as Architecture. In Software Development it describes how a solution will be built out and interact with its surrounding environment – very much akin to a building Architecture.
We can also understand the value of good solid foundations.
We know that if we want our house to last the test of time, that we will need solid reliable foundations. We then need all the good things that we expect from modern house building – security, protection from the elements, utilities such as water and electric, etc. We also expect that we will need to carry out maintenance during the life of the property – the costs do not end with the build.
And this is true also of Software Development – our cost is much more than the initial build. We also have to factor in the maintenance and upkeep of it over its lifetime. And in keeping with the house building analogy, the better the job we do in the initial build, the cheaper it will be to maintain during that lifetime.
If we use cheap products and poor construction techniques in our building, then we will have a very expensive ongoing maintenance cost. Potentially, if we’ve done a really poor job, we may need to pull it down and start again. Luckily, in construction, we have evaluators (Building Regulations in the UK) to ensure that reasonable standards are adhered to.
The same does not exist in Software Development. Not without investing the time and effort to ensure it is put into place.
Another great use of the House Building analogy is when considering change after the initial build.
If you want to add an extra room to your house, you would expect to go through the appropriate steps to ensure that it is integrated into the original house correctly. That may require changes to the original foundations or architecture so that addition is in sympathy with the rest of the property.
Otherwise you run the risk of making your entire house unsafe and unsustainable.
Again the same is true in Software Development. But it isn’t visible, thus will not be as instantly recognisable. Sometime we may want to add what seems to be the most innocuous thing – but requires significant change to ensure that the integrity of the overall solution is not compromised.
All in all our analogy can be a great way of getting that meaning across.
Ok, so now onto the dark side of the analogy.
One of the biggest gripes I have, is the expectation that any Software Development project should be able to provide 100% correct cost & time estimates up front – just like “building a house”. Right, the first thing I’d ask is if the requester has ever commissioned building work. Certainly my personal experience is that construction is not a yard stick by which to measure the infallibility of predictive estimation. It’s common for delays to occur due to weather, suppliers or a host of other factors – and (depending on how the work is finances) increased costs as well.
The more bespoke a house is, the higher the risk of an upfront estimates being wildly out. Anyone that has ever watched the UK Grand Designs program will be well aware that a custom build is far from a clear cut thing.
And the construction trade has been at its trade for thousands and thousands of year. There is an immense collection of tried and tested practices for both the estimation and execution on which to rely on. And they still regularly get it wrong.
Software Development will generally be a lot more like a custom build than a repeatable build that has been done 100s of times. In Software Development, if we are solving the same problem over and over again, then something is hugely wrong.
It is also well understood that change will have a material impact on our house. If we decide part way through that we’d like the kitchen a little bigger, or an extra window – we know that will require additional work. That it is likely to have an impact on cost & time.
We don’t seem to realise that as much in Software Development – maybe because it isn’t so visible – but it still has cost and time impacts.
Good communication is essential in getting the best ROI from Software Development.
Analogies can be a great tool to build shared understanding. Just remember that no analogy is 100% correct.