Let's be real: in the majority of sets you gonna work with a multidisciplinary team. You don't work only with developers, but business analysts, product managers, quality assurance analysts, security analysts, scrum masters, etc.
In fact, the technology don't exist in a vacuum, but the technology exists for serve a need. The enterprise has all the reasons to employ tech to solve problems and make processes more faster and efficient. So, they hire technology guys like us to solve these.
But we have some mismatch in our communication. How??
As technology guys, we talk about:
- Programming languages;
- Databases;
- Modelling data;
- Concurrency models;
- Pure computational logic;
But the business guys talk about:
- The yearly plan;
- Yearly budget;
- Team management;
Anyway, they use business terms to talk about the problem. How can we solve this mismatch???
The first thing we need to perceive is that we are trying to solve a business problem!!
The technologies problem are solved in majority with libraries, frameworks and operational systems and we employ all these tools to solve the business problem. We need to start to learn the domain we are targeting and try to make an Ubiquitious Language, that everyone can talk and understand.
The Ubiquitious Language
This ubiquitious language emerge as some convergence from tech language with the business language.
It's like the light blue in this venn diagram. The business guys and the tech guys will not talk about budget or databases alone, but they will try to find a common denominator between these terms to communicate better, with more assertivity, reducing the miscommunications and poor understood requirements.
The Bakery Shop Example
In the last post, I introduced the Bakery Shop Example, where I make a diagram. One interesting fact is that diagrams and documentation only support the two main things when conveying communication:
- Code (running code don't lie);
- Spoken language;
If code don't lie, we need to try to take some attention to make code that communicate good intent. If it don't communicate well, so, it's a poor code (with high probability to become legacy), and if no-one understands this code, no-one can change it and no-one can tell anything about the business rule.
The code here is a product from the communication, protocols and things that tech guys come to an agreement with business guys. Because of that, the communication, specially spoken communication, is very very important.
So here, we have a very hard difference between these two lines:
- When the user start a new recipe, the system will query the database to find if in the stock table the registries have the quantity needed, so we retrieve these entities and set to used some quantities, then save it again into table;
- When the user start a new recipe, we take the RecipeIngredientsSpec to the Stock and retrieve all of them;
Did you see the difference? The ubiquitious language is a mean to make a common abstraction here. The description is about the same thing, but the way it will influence the understanding and the resulting code will be very different!
Object Oriented Analysis and Design
Many people read some book on the matter, but still making procedural code.
Procedural and Object Oriented Code are different ways to communicate some intent through code. But they are byproduct of the language used to model things.
Object Oriented Code and even Functional Code emerges from declarative language. You don't tell how to do a thing, you tell what you wan't to do only, and make abstractions to support this.
Procedural code emerges from descriptive language, where you have to tell how to do anything.
When you employ a declarative way of talking to each other, the understanding in the project will be better, and a better design have the opportunity to emerge.
Top comments (0)