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.
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.
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.
On the other hand, if your frontend is an API or a library, there are other features that should be considered.
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:
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.