Front-End First Development?
Front-End First Development?
When developing, it can be helpful to consider the front-end before getting too wrapped up in the guts. It's a case-by-case issue, but the advantages are there.
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
Whenever a new product or new feature implementation is ahead of us, there are many ways to approach the implementation phase. Besides choosing the software development framework such as SCRUM or Kanban, we also need to figure out from what angle do we approach the implementation itself, the order of epics, stories, and tasks.
This largely depends on a few things, such as operational capacity (team size, project budget, required skillsets, etc) and type of project, but also with respect to product and stakeholders. For example, we may not have the budget for a large team, in which case things need to be done in a more sequential order. We must choose if we will develop the frontend of the app first or focus on back-end development.
If the project is performed by a large organization, such an environment allows for large teams and greater diversity of skillsets and thus has less constraints. However, even then, the question remains—where to start the implementation. Some aspects that need consideration are project risks, where the system complexity lies, but also stakeholder analysis, more specifically the influence and disparity of views and personalities, especially if the product owner’s role is not clearly defined or fulfilled.
The most complex tasks that may require investigation should be handled first because it’s better to have a few surprises earlier in the project rather than close to the delivery deadline. Development teams often prefer starting with backend of the application (server-side) as it is more complex to design, implement and test (meaning: requires more time). This is where you’d usually find the implementation of business logic and data handling as well as integration with third party systems. However, that part of the system is usually easier to specify and test for acceptance. The number of influencers is smaller and usually all of them are in your development team.
The front-end, on the other hand, is what the user sees. User experience (UX), and especially graphical design, are subject to multiple approval stages by groups of different stakeholders on multiple levels of organizational hierarchy. To top it off, most of them are non-technical people whose job is to please the end user but also, often subconsciously, influence the design with their own ideas of aesthetics and design. This is why the specification of the front-end (wireframes, design, technical specification doc) is often subject to many iterations and re-works. If the application we’re building is a mobile app or an e-commerce website or any sort of end-customer facing application, it’s always better to start with front-end implementation first.
This approach has numerous advantages. Most of them are based on risk analysis and will vary from project to project, but there are ready examples. The product owner gets a clickable model ahead of the whole system and is capable of showing it to stakeholders for an early review. Changes in functionality or business logic rules are cheaper and faster to implement (as they do not require changes in the backend), and in case you have a larger team, this buys additional time for backend design and prototyping, which, I am sorry to say, the user or top management don’t really care about. People want a rich and smooth user experience and rarely bother with what’s "under the hood."
There was a project, however, that I was not managing directly but was a stakeholder in, where the team misjudged, or should I say underestimated, the effort necessary for backend development. The project was late for delivery and the product owner had a rather large gap between what seemed like a completed product (but didn’t have all the backend functionality) and a fully implemented system. Needless to say, the customer was not a technical expert and explaining the scenario took some extra effort and a few escalation handling meetings. Lesson learned? Everyone should be aware of the approach you’re taking—you should spend some time educating your technically inexperienced stakeholders about the pros and cons of your chosen approach but also perform your due diligence in risk planning and manage expectations accordingly.
Care to share what your experiences with front-end vs backend first approach were?
Published at DZone with permission of Bojan Kovac , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.