A common developer mistake is to assume clients, stakeholders, mums actually understand the multi-layered, n-tier, decomposed modular architectures they build.
I read a piece of wisdom once that has just resonated with me as I came to present a demo of a system I’ve proudly built – but the demo UI isn’t quite finished. I was planning in my head how to explain that it does more than you can see (there’s some obvious gaps), then remembered how stupid that sounds to normal people.
Developer: Ok so here’s this amazing engine X we’ve built for you.
Client: Great, so does it do Y?
Developer: Oh sure, but there’s no UI for that just yet.
Client: So… it doesn’t then.
Developer: Oh yes it does, the core is extremely feature rich and the Z-layer, n-tier component bindings allow…
An inaccessible feature, for all intents and purposes, not exist!
The correct answer is to impress how easy it will be to “finish that off”.
If in doubt, I use the building construction analogy: “All the foundations and walls are built, and we’ve finished the plumbing. We just need to fit-out and decorate before opening to the public.” From this a non-technical client can understand there’s still a bit of important work to do (possibly even functionality-related), but we’re over the hump and it’s more straightforward work from here, and will even start to look nice soon.
The more I use the building analogy for development work, the deeper I find it matches, from the importance of architecture and foundations, the sequence of events, roles, responsibilities – all have analogues. In fact rebuilding my house gave me some real insights into running a software team, and even how a mature industry such as construction could provide guidance to one so young as software engineering – like universal standards for example!
While this kind of cross pollination might be far fetched, you’d have to admit a building without any doors or windows is just as useless to a person as a software feature with no interface.