Not every time we know our clients' business. At least not at a sufficient level to be able to translate their internal processes into an application or a service. And it is difficult to "materialize" a design or architecture that is not in your head. Some mental tricks, and a bit of imagination, can help us bring your internal logic to a more familiar environment.
Zoo Management Application
It must be something complicated to manage: few people will know how they work. But I'm not going to talk about that difficulty... I'm going to turn it around: the security around one of the projects I was involved in a while ago was such that we couldn't know what the "things" I was managing really were. All the entities of the business, the actors, the processes, were acronyms of which it did not have the real meaning. It is very difficult to manage and code the abstraction that a CZ sends a TR to a GSH, as long as a high level OM validates it. It is blind programming.
So I changed the client's business to zoo management. In my head, a Caretaker sends Food to an Elephant, as long as a high level Veterinarian validates it. This brought down the internal procedures of the application, and the system began to make some sense. It's kind of "pilgrim", but functional. By giving this meaning, the rules that managed the system were much clearer: there were food containers, of different types, which may or may not be suitable for different species. The whole environment was governed by a series of positions, director, head of mammals, of the aquarium, which validated or not the different operations, and managed the budget of the zoo.
Overall the experience improved communication. The client, who took it in stride, could talk to me about the business, without fear of telling me more than he knew, and I understood what he was talking about. The work was much more fluid, because we could both speak the same language.
And I must admit that it is also more jovial and pleasant to work in this way.
The mental image of the churrera
Changing a procedure or system to a mental image, from something more familiar to us, can help us work on its analysis and implementation.
- A file data extraction can be turned into a churro, in which the files enter at one end, go through a series of "boxes" that make processes with their data, and end up in a container based on their content.
- A cluster of machines can become a giant spider, with each leg doing an orchestrated job from the spider's head. Nests of small spiders take over the task process, ordered by "mom".
- A network architecture can become the wiring of a house, the door to the street is the external firewall, and the coat rack at the entrance is a honeypot to distract intruders.
An end user and even we ourselves will probably understand better that your already printed files go into the "discard drawer", than into the "historical file repository".
The reinforcement of the mental image
As a rule, we do not work with actual data from our customers, but generate and manage our own development and test data set. This data can be translated into names and data in our application, modelled to reinforce mental image.
If these data are correctly related they will reinforce this illusion, which will help us to manage the system in a more tactile and closer way. By translating abstract, sequential, self-generated data into something more real, we give them a meaning, a semantics, that helps in the composition of the real work.
They can also help to detect and minimize problems in applications, improving the quality of applications and services "at no extra cost": If on a screen of our development we see that *USER001 sends a message to BUZON_56″, it will not call our attention: it may be correct or not. On the other hand, if in a screen of our development we see that *ACUARY_CAREER sends a message to BUZON_REPTILES", we will instantly realize that there is a problem with our process: that user should not be authorized to use that mailbox.
Let's avoid the niches
A doctor, a policeman, is presumed to have a vocation. A computer scientist is presumed to be a geek. In both cases, I think it should be a requirement, not a competitive advantage. Without going off topic, assuming this mindset, we may be tempted to take these visualizations into our favorite hobby. Loading data into the system based on our favorite computer game, or characters from the Game of Thrones series, or the Star Wars saga.
I knew a programmer who named his variables after Roman emperors. He was studying history. In his code there were things like public Vector viriato = null;
Let's not. If the idea is that we "materialize" an abstract system, we shouldn't do it in such a way that only we (or Star Wars fans) understand the data. Even more so when we work in a team. Let's use general ideas, that everyone can understand.
The name of the wind
Abstracting the systems, and data, to images more familiar with us, with known names and concepts, can help us to carry out our analysis and development work more efficiently and coherently, improve communication and understanding of the system, as well as reduce incidents.
And... not least... it also makes the job more enjoyable.
