People tend to overlook things when developing a new software product or service because they don’t have to think about them on a daily basis. Companies should create an environment where everyone can express their opinion and concerns and encourage bringing up questions to explore different angles and increase understanding.
Ilian Iliev spoke about why people tend to overlook things in software development at Dev Challenge Accepted 2023.
People tend to overlook things not because of a lack of knowledge in the team, but more often they are forgotten because they don’t have to think about them on a daily basis, as Iliev explained:
A simple example here is metrics and monitoring - of course everyone knows that they need to have metrics on their API performance, success/failure rates, etc. But exactly because all our projects already have them and they are such a common thing, we never think about them during the planning and just forget them.
Teams that start new projects are often more aware of all the tiny parts that are a vital part of the base setup, Iliev said. If you have worked on the same thing for a few years and now you have to start a new project, it is quite likely you will forget some of them.
Iliev mentioned that during architecture and planning people get so focused on the actual functionality, that all the surrounding pieces get blurred and slip away, similarly to getting tunnel vision while driving on a highway.
He suggested bringing up questions from everyone on the team as early as possible, as that helps a lot to ensure that everyone fully understands the project and its details. Everyone is a stakeholder; we just look at it from different angles, he argued:
For instance, product owners look at the end result, architects at the overall system design, and QAs at quality. But no matter from which perspective you are looking at it, the better you understand the problem with all its specialties, the better solution you can provide.
Companies should create an environment where everyone is open not only to asking questions, but also to expressing their opinion and concerns, and employees should learn how to express themselves, Iliev concluded.
InfoQ interviewed Ilian Iliev about things people tend to forget or ignore.
InfoQ: What made you decide to explore the things that people tend to forget or ignore when developing a new software product or service?
Ilian Iliev: It comes both from my own experience, as well as talking with other people in the software industry.
One thing I actively work on, next to creating stable and useful software, is improving the development process. In the end, everyone should be happy with the result and there should have been a minimal amount of stress across the team, and every piece we miss takes us further from that goal. So I will look at how to avoid those little cracks in the foundation that tend to get larger with time.
InfoQ: What are the things that we tend to overlook when architecting the system?
Iliev: One of the main issues I often see ignored is the (de)coupling with the existing codebase. People often tend to go to extremities either by adding unnecessary levels of isolation or making the new parts so coupled with the existing codebase that separating or replacing them at a later stage results in major system refactoring.
Another one is maintaining the compatibility of your system when you have to support multiple client versions, for example when you work with mobile apps and you lack control over when the end users update their devices.
InfoQ: What are the missing parts during the implementation of the system?
Iliev: When creating tools for non-tech users we put a lot of effort into making user-friendly and intuitive interfaces. On the contrary, when the user is a fellow developer we often neglect that, assuming they have extra knowledge about the problem.
For example, internal APIs often lack documentation and we rely on some tribal knowledge of what does what and what each field means. And tribal knowledge is fragile - people take vacations or change jobs, companies hire new employees, and suddenly everyone realises that having a single source of truth easily accessible by everyone is not just a convenience, but a necessity.
When we look at a code level it gets even worse - we rely on the fact that developers can read the code and assume that this solves the problem. The reality is that reading the code is hard, as attribute names that made sense when the code was written might no longer make sense. On top of that, reading the code tells us how something works, but not why it is made this way. All the reasoning behind a complex decision is gone.