Software is a House
Software is a house. An intranet is a gated community and a proof of concept is nothing but a model home. To software people, these analogies are novel. To non-technical clients, they can be the difference between confusion and clarity.
We have all been frustrated by the communication gap between domain experts and non-technical folks in software. Clients struggle to understand why a "similar" update will take two weeks instead of the two hours the last one took. Developers, when asked a tech question, may explain it to their heart's content, blissfully unaware their audience hears nothing but Charlie Brown's teacher.
What would serve us well is a similarly complex, but better understood, medium to draw analogies from. I have found the analogy of a house works well.
Let's explore some basic analogies we can draw from the software is a house mindset. And then, using this basis, we can all work to improve the communcation between engineers and our clients.
Model homes
Years ago, i had to explain to a client why it was easier to rewrite a proof of concept than to simply make it production ready. Looking back, i'm certain my explanation was both overly verbose and grossly inadequate. Since then, i've learned that the house analogy makes the explanation a lot simpler.
When showing off a model home, the focus is on the interior. You see the carpets and the curtains. You can tell if there is adequate cabinet space. The sinks may look nice, but does the water turn on? Does the home have heating? Unlikely.
Software proof of concepts are the same. The focus is on the client experience: do they like the layout? Does the interface flow like they expect? Once the client agrees to this, engineers will usually suggest rewriting the project. The reason comes back to the house.
If i buy the model home, it still needs plumbing. It needs a foundation. We can't have a crane put the house onto a foundation. Worse, need to tear the walls down to put in the pipes. It would take less time to just rebuild the house on a freshly poured foundation.
Software is no different. It is cheaper, and more reliable, to pour a fresh foundation and build from scratch. The difference is we now know with certainty what we are creating, and where the concrete goes. In the end, this makes the process go faster.
Adding context to scope
One of the hardest things for clients to grasp is the level of effort changes between seemingly similar tasks. Again, the analogy that software is a house can explain this.
A client will agree that it takes very little time to move a dining room chair to the living room. They will also agree that it would take much longer to move the toilet into the kitchen. But why? Both are things people sit on. All we are doing is moving each to a different room. The level of effort should be the same.
The difference, of course, lies in the hidden details. The plumbing, quite literally. Explaining this to clients helps immensely. As a homeowner, i dont need to know how my house's plumbing works, but i do realize it would be an effort to modify. The same can be said of clients' grasp of software backends. We just need to draw the parallels.
Gated communities
"Intranet" is a tech term that often get repeated by non-technical clients. A client once told me that i would need to retrieve a document from a machine on their intranet. I sighed, audibly.
Why, she asked, when given the address of a machine on their intranet, i could not simply connect to it. I explained it is because an intranet is a gated community. Just like a gated community, when i am given the address of a house, i may be able to identify the neighborhood and drive there, but without the key to the gate, i cannot arrive at the house.
The same works for machines on an intranet. Once inside the community, computers can talk freely. To users outside of the gate, and thus the intranet, we need a key to the gate as well as the address we are looking for.
When she asked who had the key, i responded, "your I.T. department". Now it was her turn to sigh. We were finally speaking the same language.
Communication is king
The parallels i've listed in this post are just some of the ones i have used over the past couple of months. I am still discovering them using this analogy.
In the end, the trick with analogies is knowing when they are useful and avoiding them when they stand to further confuse someone. If there is a formula to identify those situations, i have yet to find it. But through trial, error, and continuous improvement, we can each work to bridge the gap as best as we can.
And my bridge starts at a house called software. Even if that means clients refer to my code as chairs and toilets.
