You could say that software development is about code. It’s true at the technical level when we’re solving problems as individual developers. The other aspect is the communication within the team and with stakeholders and other people. Out main goal after all isn’t really the code itself, it’s to deliver business value to the mythical production environment.
Linguistics of the development process
We’re all speaking English (or your home country language) in the office so why we can’t understand each other?
Let’s get a step back and look at the development process from some distance how we deliver a feature to production.
- First someone in the business notices market opportunity of implementing certain functionality and estimates that delivering it will bring profit after the cost of development
- This person speaks with executives to get the validation of the idea from management
- After the idea is approved Product Owner and/or Business Analyst is notified and starts a series of meetings and workshops with people who know what needs to be done to flush requirements
- Those requirements are translated into technical terms with help of the development team
- Development team creates code representing the functionality in the company application
- Testers are checking if the functionality work correctly and if there is no bugs
- Operations team deploys this functionality to production
- Users can use new set of features and business is earning money as expected
That’s a lot of work and a lot of different people involved in the process. A lot of different departments as well.
Delivery of the feature
If you are a technical company or given feature is purely technical it’s an easy task to communicate and measure the results. Kind of. To see better the communication gap let’s take a feature from finance sector, for example accounting. Let it be a ledger to track all the money movements within the company.
Do you know what ledger means? You don’t really have to for the time being. The accountants know what ledger is and how they want to use it. As they requested the feature they will come to you and explain what is in their mind and how it works. And they will use their own financial/accounting terms to do it and you may not understand a work they’re saying. Then you ask questions in technical language about database schema and it will be their round to not understand what schema is. In the meantime both of you will omit few important things you take as given – like precision of the numbers representing money, currency tracking and that amounts can’t be saved as floats.
Thankfully there is a BA and PO to help with translation between the languages and then release manager and devops BA to help with translating infrastructure requirements to what company can do. They will help with finding common language between the departments and respecting this language contract is a key point in reducing cognitive load during development.
What is the Cognitive Load?
Wikipedia has a good and quite expanded definition. In our case we want to focus on keeping things simple. Cognitive Load is the effort it takes to think about a problem. You can’t avoid it but you can focus on spending it in the best way possible. Think about it as mana pool for RPG character. You have limited amount of it and you need to be smart using it.
Let’s have a look at example of how unnecessary cognitive load can be added to the project and how to avoid it.
People requesting a feature talk about Ledgers being implemented. As a development team we use term
Account as we’re not that familiar with the term Ledger. The translation from one concept to another may not seem like a big deal with time the scope will grow and new terms will appear. More translations you’ll have in the process the more and more you’ll have to focus on keeping translation right. Not only for the code but also in the meeting with stakeholder where you’ll translate on the fly between your and their language.
This is an example of cognitive load, where you spending your mental resources on non-trivial task of translating terms when you could use business language in the code to smooth things up. At first you may say that it’s not really a big deal but is it really?
When you discussing a feature you need 3rd party to translate between two teams. Having another person in the communication chain slows it dramatically. Communication is as fast as the person can reply and they usually deal with multiple projects so it amy take a while when you and your stakeholder could speak directly.
It also helps with new features and finding bugs. Either it’s a new feature of adding multiple transactions to a ledger or some problems with balance calculations you’ll be able to find the place in code related to a problem way faster using business language. Stakeholders will basically tell you the name of the class in question. You can also use the name for tests, BDD style, where business problem becomes a name of the test and core of the feature description becomes the body of it. With core reflecting language you may even get to the point where business person can verify if your test is right.
I’d like to mention is the onboarding process of a new member of either team. The first thing they need to learn is th language of the domain they will work on to understand what they do. Usually it takes reasonable amount time on it own and translation makes it that much more difficult.
It’s all nice but what to do when you’re in the translation heavy place? Start small.
Renaming methods, writing better named code by yourself is a good start. But respect team language and get everybody on board before big refactoring. As nice it may seem using new language in the team of people used to translation layers isn’t a productive practice. Be agile, make small improvement and in time the language will shift. It may take years before it really happens but the patience is a virtue.
Simplifying language with a team and company isn’t a simple thing. People have their habits and they die hard. Therefore effort needs to be made but it’s a good kind of effort. I’d say it’s better to spend time on thinking about improvement than translating terms. In the case where you can’t directly translate you may think about using decorator pattern on the language level. An User Error becomes User Error Response with 400 HTTP code.
Reducing cognitive load will save your time and energy on daily basis. Saved time you may spend on solving problems important for business and development team. Most importantly though it will save your mental energy and will limit the stress level you’re facing while working. This alone should be a good enough argument to at least give it a try.