Could visualisations make programming more transparent?
Programming, Magic or Boredom? — Part 2
In Programming, Magic or Boredom? — Part 1, I expressed a need to advance from the era of a “text input, text output” style of programming. I would like to take the next step by exploring the transparency of programming.
Say you are holding strings of yarn and they are all knotted and tangled up. Everyone can see that immediately, even without having a clue on how to sew something. Software, unfortunately, is not like that. Software can’t always be judged by its cover.
It is an easy task to make code work, meaning you get the outcome intended. Anyone can do this. But it is not an easy task to make code work and nurture a complex codebase for years with a team of peers and multiple stakeholders. One usually learns the difference between the two scenarios when it is already too late. Business-wise this can have major negative implications.
A codebase which aims to strive needs nurturing as software has a tendency to spiral towards becoming an incomprehensible mess. Most developers do understand this. But let’s remember the majority of people only see the user interface, and there is much more to software than pixels. The faceless back-ends, APIs and microservices do not like to expose themselves. Thus how does everyone, business stakeholders included, realise when the quality of the software has been neglected for too long? How can we truly understand there’s complexity needing to be tamed? When is it time to rethink the architecture which has scaled just fine so far?
I would suggest you need to be able to see the inner workings of a software. And I mean really see it: the size, the structure, the dependencies, and the complexity. Instead of trying to read through the code and map all the said aspects in our head, we could visualise the codebase for everyone to see.
“What’s new?”, you might ask. Some have planned and visualised their code structure, usually referred as architecture, for years e.g. using UML (Unified Modeling Language). In the physical world, architecture starts with a plan and manifests as a building. To emphasise, the plan is not the same thing as the end result. We have transferred the same ideology into the world of programming by having software architects drafting plans, and programmers building software according to the said plans. But in the world of software, the plan could be the same thing as the resulting software, and vice versa. This way, instead of having plans, documentation and then the actual software, we would only have a singular source of truth.
What could be a good form of a software visualisation that’s both understandable to people and still translatable into code? In addition to having structure or architecture, programming also inhibits processes. Therefore I would suggest the following analogy: making software is like building and maintaining a factory (without almost any physical limitations). What would our factory (or factories) look like then?
- There would be machines (services, classes, logic) to produce something in order to fulfill orders (usually e.g. information that someone has requested). Machines would contain code in the same way as files do.
- The machines might need certain material as an input (other data) to be able to produce the expected result. Sometimes this material comes from an operator (through a user interface).
- Machines would be connected by e.g. conveyor belts (dependency injection).
- Some of the manufactured end-products (information) would just go out of the factory (e.g. a HTTP response), but some of it would stay in our warehouse (database).
Of course, the visualisation of our factory would quite likely turn out to be formidably complex and even messy. Because that’s what software usually is, we might just be blind to it. Also, let’s not forget a factory being just one way of representing the inner workings of a software (apologises for bringing up such a non-magical idea). Could we view a codebase as a hierarchical organisation, a lively city or a growing forest? Perhaps there’s an even better option, or options, waiting to be discovered.
But imagine seeing your actual codebase become alive! The lines of texts have been materialised as something more tangible. You will see the effects of taking shortcuts, the ongoing changes in architecture, the utmost importance of a certain piece of business logic et cetera, right in front of your eyes without doing as much of additional mental mapping. I suppose it would be easier to welcome intuition, too, as people are e.g. quick to categorise things visually. What’s even more important, we are able to show the codebase to someone without extensive coding knowledge, and they might actually be able to understand something of it! Quite useful if trying to explain why implementing the latest requirements takes a bit time (a complex feature which has multiple interdependencies) or why the team is getting a bit too small (an ever-growing codebase with very specialised sections). And if you do make mess, people can see it.
I could go on, but I think you get the gist. Suddenly the process of creating software is more inclusive.
