DEV’S POV
How to Keep Your Software Balanced between Developers, Users, and Stakeholders
Understanding processes and patterns
Expectation and resource management can be very exhausting, and team members don’t seem to help! Frontend vs. backend holy wars demotivate the team, and there is seemingly no common base. Let’s decipher the secret laws and mechanics of the software development delivery chain.
Triangle of software development
Similar to a triangle of expectation, I came up with a triangle of software development:
Your software can be universal and easily maintainable but barely understandable for the user. It can be easily maintainable and usable but not rich in functions. It can be very appealing to the user and have many functions, but not easy to deploy and develop.
Let’s check it out at an example of a car store, my favorite topic.
Universal + Maintainable = not Usable
Your car store lists all possible models of cars, their manufacturers with contact data, their technical parameters, their history of production, thousands of pictures, but it’s practically unusable. Maintainability is okay: you give what you got in the database, without bothering too much if the user wants it or not, without building too heavy database requests.
It’s complicated and overloaded with details.
In the real world, think of Django Admin: an easily extendible yet powerful site administration framework known for its speedy development possibilities. The views are easily coupled with queries, and the interface gives the user a simple way to execute the common operations with data.
The problem is: it’s ugly. It is just repeating the Django models visually, which normally don’t make sense to non-developer users. The interface is old fashioned and overloaded with functions, offering a poor usability concept not releasable to the highest standards UX nowadays.
Maintainable + Usable = not Universal
Your car store lists multiple models of cars. The interface is appealing to the user and their needs. You have decided to keep your application minimalistic and removed everything not needed.
The users complain they can’t find the year of production, other associated models, and car insurance costs. You, afraid of becoming a typical deutschtech website, dodge the user requests and keep going your way. Some users leave because they don't get what they need despite the attractive interface and outstanding usability.
In the real world, think of Trello when you image such software: elegant, clean design, incredible UX, but you won’t be able to organize teamwork with permission handling or fully enabled software development in it, it just misses the necessary functions for the sake of usability.
Universal + Usable = not (easily) Maintainable
your car store is easy to use, has a single search bar. It contains millions of cars; artificial intelligence predicts the user preferences and associates products. The UI is clean and intuitive. Necessary elements show up exactly when the user needs them.
But it’s a huge piece of work. Tens of docker containers and databases replicated over 8 different regions, millions of code lines, three steps of QA, various testing mechanics, and processes. This is what your application is under the hood.
Your hosting and service bills are in five digits per month. Your application's innocently looking interface, welcoming the user with pastel colors and amazing graphics, is covering the monstrous mechanism of overwhelming complexity with thousands of people involved.
In the real world, think of Google: its signature design ultimately recognizable everywhere on the planet hides the incredibly complex server landscape, AI, and whatnot, to guarantee the astonishing SLA Google is known for.
Outsiders and Outliers
Having two out of three edges of the triangle is not necessarily given. Some applications fail to achieve even that and hang around only a single quality. Look at how most of the German internet looks like:
There are plenty of such sites on the internet, and again as in Conway law: the product reflects communication. In this case, it reflects the competence distribution in the team.
Supply chain paradox
Apart from the communication problems, which are quite natural when the working material is still forming, there is one more problem. I call it the supply chain paradox.
Let’s take a look at the common interactions between the frontend and backend developer while developing a single page application, for example.
The main tasks of the backend are:
- execute the user requests, translate them into database queries
- effectively store the data
- minimize the data satisfying the user requests
- minimize the processing time
- manage data access, roles, and permissions.
So the ideal situation for the backend is when the are no users. All goals are achieved:
- no users — no requests ✔
- any data storage is effective because no one is asking for it ✔
- no requests — no data ✔
- no data — processing time zero ✔
- no requests — no access management ✔
The frontend on the other side, has the following tasks:
- show and organize the information and controls in the way most suitable for the user
- translate the user input into server requests
- translate the server responses into the local data model
- translate the local data model into graphic elements and controls
The ideal situation of the frontend is:
- there are no users ✔
- the frontend has the whole database locally ✔
This is a major conflict: the contradicting intentions cause the developers to see the problem only from their point of view, triggering the long discussions about why the ones do not care for others’ problems. While every stage is the part of the processing chain, from the user to the database and back again, they constantly fight each other on the responsibility area and service levels.
The same works for designers and frontend, for example. The best design for the frontend is a big green button with “solve all problems” on it, while the best frontend from the design perspective is a pixel-precise copy of the design, which is far from doable in reality.
And this is the supply chain paradox: to deliver the best quality software developers need to overcome the oppositely directed interests and find the middle way. They need to do their job considering the neighbours’ interests too.
Conservation of developing power
The triangle of software development and the supply chain paradox are connected. Any disbalance in the supply chain from designer to database engineer is immediately reflected in the product.
So, if the frontend dominates the decision making, the application will be usable and good looking, but the maintainability and universality will suffer.
If business playing I’m-the-boss-driven development, your software will be full of features, but no one would be able or want to use or maintain it.
In the case your application is imbalanced towards the backend, you’ll get an ugly and useless app nobody wants to use, but it has the best database performance in the world.
Balance
Nature loves balance, so does the software. Keep the interests of all participants in the supply chain in balance, and your software will live long in prosperity. 🖖
You can’t have all at once, so in the first place, start with a compromise: what is important in your case: universality, maintainability, or usability?
Thanks for reading. Subscribe for more interesting content!Also, check out my recent articles:V
🍑 Fullstack my backend: why full stack developer is a myth
🕒 Why your software quality degrades with time: short story
🐍 RapidAPI: first steps with Python: a comprehensive guide
