Any senior developer knows that by far it is better and easier to start first working on a software project on the back and after on the front end. Personally, when it is possible for me, I like that approach a lot more.
However, we have a very important factor that usually make us changes the order: The Client or the User. (Hereinafter referred to as the user).
Unfortunately, in most cases the users, although they believe they know what they want, when creating stories or requirements they will always forget or omit things and, they believe that things are done in a way but actually are done quite different. In other words, 70% of the quality of the requirements depend on the User.
Most of the times the developers and the teams are quite good, skilled and professional. The projects don’t use to fail due to the lack of the technical skills. Sometimes it is not possible to see that the poor quality and management of the requirements is what make the projects fail most of the times.
In a side note, managing and assigning tasks to the team is not related with the requirements management, a lot of teams mix the tasks with the requirements. They need to be manage completely separated. When you manage the requirements you ensure your application does what it supposed to do by ensuring that the user receive everything that he ask for; when you manage the tasks you ensure that the people on the developers team are completing things, that they are not blocked, that they deliver, that the deliverable is a quality product. The agile methodologies usually only take care for the task’s management and very briefly on the requirements.
Getting back, to mitigate the requirements problem, when the users don’t have a clear idea of what they need it is advisable to do a Functional Prototype. In software development is not the most optimal way to create an application, usually take up to 50% more time and resources to complete a project, but you minimize the risk of being in an infinite loop of changes and software refactors when you try to deliver the project because the application will not do what it really needs to do.
On the Functional Prototype you first make the entire Front End with all the navigation and data validations. You don’t work on the back end, database design or anything like that. It is the user responsibility to review, navigate and validate that the prototype complies with the needs required for work process needed to be done by the software. Usually this will need several to come and go until everything is in place.
For sure the user still will forget things and it will make adjustments after the Functional Prototype is done, but you have reduced this by 10 to 1 scale, since by seeing the tangible part of the application the user more easily will remember what he needs, what he is forgetting or how the work process actually is done. It will be a lot much easier to change and make any kind of adjustments only the front end, rather than having to refactor all, Front end and Back End and having to run regressions tests.
Once the Functional Prototype cycle is done, then we proceed to connect the Front End and the back end. As I said, and I emphasize, in terms of development it is not the most optimal way to work on a project. You will develop much faster and more efficiently if you start with the back end.
With a Functional Prototype what you do is minimize the risk that the project fails when you don’t have clear and quality requirements, otherwise the project will turn into chaos since the user doesn’t know what he needs for the project, even if he thinks he does.