[Versión en castellano]

When you begin the development of a new software system, you must answer different questions. While you might be tempted to focus on architectural issues or technology selection, there is a key point that shouldn’t be forgotten, that is your user.

01_POST_SEPT

As obvious as it may seem, we develop software systems for the people who are going to use it. As you should know, when people intervene, feelings come into play. Therefore, all your work is going to be questioned, praised, or even hated in a few minutes or hours; not to speak about bugs.

Supposing you were a backend guy you could argue that button color isn’t your problem; on the other hand, if you were a frontend one you could claim that database performance isn’t yours and even being a frontend’er or a backend’er you could make the API girl accountable for all the communication issues. If you feel identified in any of those situations, I dare say that you and your team have a problem! Your users see the system as a whole, so they don’t really care where the problem is.

00_POST_SEPT

Hence, assuming we should focus on our users, question should be where we shall start. Actually, the answer is simple, on your user interactions. You could wonder what I’m talking about, let me rephrase it:

Your main effort should be in providing your user an actual working environment where they can verify if your software works as they are expecting.

As a matter of fact, accomplishing this task involves taking both a frontend first approach and a modular one. Before describing what I am talking about, I would like to clarify that frontend is not only a typical web-based or app-based one, but also your API if your product or project is intended to developers and you offer a REST, OpenGraph, whatsoever interface.

Once agreed on what is the frontend I am referring to, let’s discuss which are the different key points that should be considered, obviously some of these points only apply to a typical frontend.

• First of all, a working environment isn’t a UI prototype, but a system where a user can interact, therefore reactive to user input and offering outputs to certain requests.
• A working environment isn’t an ended one, but a growing one in which we are adding functionalities in a system-centric way of thinking. Thereby, if authentication is critical for our application, our first iteration should include its emulation.
• We should deliver new functionalities and changes as soon as possible, but we should implement them in a modular way since we must avoid that a new functionality could break tested behaviors.
• If our application involves an API or a middleware, its design should be a consequence of frontend expectations. Considering the modular approach discussed above, our API isn’t a monolith but a set of independent, although related, APIS.
• Once our frontend complies to user expectations, we can start backend development. It’s important to note that user should be involved in verifying end-to-end functionality and don’t forget that backend is the actual responsible of data control, security, and quality, therefore all checks should be duplicated on backend side.
• Moreover, we shouldn’t forget our responsibility as developers, that means quality and that involves testing. Hence, unit testing, in a behavioral approach, is a must, for your frontend, your backend and even your APIs.

02_POST_SEPT

On the other hand, if your frontend is an API or a library, there are other features that should be considered.

• Focus on what developers expect, don’t create nonsense nightmares. As a matter of fact, there are hundreds of APIS that are pretty bad designed, even commercial ones.
• Good comments both for methods and input and output objects.
• Whether information is required or not.
• A minimal number of objects, abstract whenever is possible, avoid duplication both of objects and functions.

Be that as it may, this approach also involves an architectural one in which mocking and modularity are core features. Hence, from a technical point of view, how should you create your tech stack? In my opinion, there are different approaches which could be considered:

• You should select a frontend architecture that allows a proper separation of concerns. Please, don’t mix accessing data and painting it on screen! Probably your view will change a lot, but your access data functions won’t change so much. Isolation is key to prevent errors. Moreover, the more isolated the layers are, the simpler mocking will be.
• You should work with your backend or middleware pals, or architects if that is your organizational workflow, to define properly how interactions are going to work, avoiding duplication, or providing adequate abstractions for the sake of example.
• On the frontend side you should give a try to micro-frontends architectures using an aggregator to provide your system with transversal features as global authentication, micro-frontend embedding, global communications, logging, etc.
• On the backend side any of a modular monolith (using different ClassLoaders if you are using a Java based application) or a microservices architecture could fit the gap smoothly. I’m not going to discuss which one of them is better. Actually, it depends! Nonetheless, I’m a great fan of modular monoliths.

In my experience, implementing this method in your software developing process is a win-win situation. On the one hand, the user will be involved from the very beginning, hence its satisfaction will increase; on the other hand, you will be focused on functionality and value, therefore you will avoid future problems.

Hereby, involving your users from the beginning, providing them with an actual working environment, being agile in offering results are essential and differential. Technology is important, but that is more related to maintenance and extensibility than to the initial user satisfaction. As you can see, developing software is a complex task.