Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

When to Start a Project With the Front-End

DZone's Guide to

When to Start a Project With the Front-End

Borrowing from Agile methodologies, a developer discusses why, in some cases, working on the client-side prior to the server-side can make sense.

· Web Dev Zone ·
Free Resource

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Any senior developer knows that it is better and easier, by far, to start working on a software project on the backend and move on to the front-end later on. Personally, when it is possible for me, I like that approach a lot more.

However, we have a very important factor that usually makes us change that order: the client or the user (hereafter 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 also they believe that things are done in a particular way, when, in fact, they are actually done quite differently. In other words, 70% of the quality of the requirements depends on the user.

Most of the time developers and product teams are quite good, skilled, and professional. The projects don’t usually fail due to the lack of technical skills. Sometimes it is not possible to see that the poor quality and management of the requirements is what makes the projects fail most of the time.

As a side note, managing and assigning tasks to the team is not related to requirements management; a lot of teams mix the tasks with the requirements. They need to be managed completely separately. When you manage the requirements, you ensure your application does what it is supposed to do by ensuring that the user receives everything that they ask for; when you manage the tasks you ensure that the people on the development 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 of the task management and slightly touch on the requirements.

Getting back on track, to mitigate the requirements problem, when users don’t have a clear idea of what they need, it is advisable to do a Functional Prototype. In software development, it's not the most optimal way to create an application; usually this takes up to 50% more time and resources to complete a project, but you minimize the risk of being in an infinite loops 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 backend, database design, or anything like that. It is the user's responsibility to review, navigate, and validate that the prototype complies with their needs. Usually, this will require several tests go until everything is in place.

For sure, the user will forget things and will make adjustments after the Functional Prototype is done, but you have reduced this by a 10 to 1 scale, since, by seeing the tangible part of the application, the user more easily will remember what they need, what they are forgetting, or how the work process actually is done. It will be a lot easier to change and make any kind of adjustments to the front-end, rather than having to refactor the whole application (i.e. front-end and backend) 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 earlier, 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 backend.

With a Functional Prototype, what you do is minimize the risk that the project will fail when you don’t have clear and quality requirements, otherwise, the project will turn into chaos since the user doesn’t know what they actually need for the project, even if they think they do.

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Topics:
web dev ,front-end development ,agile software development ,agile web development team ,backend development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}