17 Aug · 9 min read
Learn why you should care about how you organise your frontend development and platform integration teams, what effects different approaches have and how it impacts your web development project.
Nowadays there are probably few that need convincing on the importance of a modern, well performing frontend for the overall quality and impression of a website. At the same time, by now it should also be well established knowledge that slicing your development horizontally (in our case frontend and backend) and delivering those layers completely independently will hardly ever lead to good results. So what is the most effective approach then?
Let us assume the time has come for you to create a new or relaunch an existing website. You have already chosen the right underlying platform (be it e-commerce or content management solution) that suits all the needs of the 21st century. Everything is well planned and now you just need to make sure that your project is successfully implemented. Fortunately, you have already contracted the team mastering the platform of your choice—so everything should go smoothly, right?
Hang on a minute. What about the implementation of the frontend part of your project? All these attractive, eye-catching designs need to be translated into a well-performing HTML, CSS and JS trio. There is a chance that you are tempted to pick another team for that—be it to avoid lock-in with one service provider or because you have already chosen a separate creative agency which also offers to deliver the frontend work for you. After all, frontend technology is pretty standardised and there should be no problems for other developers to work with that, right? The short answer is: Nope.
From our experience, that is a very bad idea (been there, done that). It often leads to higher effort (and of course costs) or lower quality, or both actually (in most cases). And here are a few underlying reasons that we are happy to share with you:
Frontend developers can easily translate designs into a seemingly shippable product via a browser (or a good looking clickdummy). The trouble is that it is almost infeasible to design all the possible cases for lets say product detail pages (imagine the number of combinations of product name, general information, features lists and marketing materials associated with a product, product gallery, etc.). That means frontend developers only ever work with a very small subset of real content (combinations) from your website. On larger websites that is a real problem in particular. If we don’t communicate in detail on the elements we intend to reuse or combine later on, there is a very high chance they will hardcode values or write their code in a way which later makes the required recombination impossible. The more information about the final usage of the frontend you pass to the frontend development team, the less work will be needed afterwards. A more detailed example for entertainment: Lets say you forgot to mention to the frontend developers of the creative agency, to not just implement designs 1:1 and not consider re-use and re-combination, you may end up having troubles using that accordion component twice in one page. We have seen implementations in which clicking on the first element in one of the accordions you were actually expanding first elements from all accordion components on that page. And assuming you claim that a separate team of frontend developers may implement just the look (HTML and CSS) and not necessarily the frontend logic of a website this point still holds true—plus we would not actually get a fully implemented frontend and much work is still to be done by someone else. And one last example falling into the same category: if you forget to pass the information to your frontend developers, that there is a plan to support multiple languages, your beautiful design will likely end up looking horrible (among other based on word lengths) and much of the fronted code may require refactoring.
It is really tempting to do frontend separately from backend development—and there certainly are projects in which that is possible. But you need to be careful as it is hardly ever the case for projects built on top of most e-commerce or content management platforms. In our experience in many of the enterprise-ready, well-established platforms, the API between your frontend and backend is defined purely in terms of HTML, CSS and JS. It means changing one of those elements likely affects your integration. Why is that important? Mostly because you cannot simply take HTML created by a (separate) frontend development team and just drop it into your platform integration project. Instead, there is probably a (hopefully not too proprietary) system-specific templating engine that comes with your platform, that transforms the data supplied by editors into HTML. Since frontend developers often don’t have direct development access to the platform, this parts will usually be done by backend/platform developers. Now imagine a long list of changes (change requests, bug fixes) applied by frontend developers (to HTML, JS and CSS). Once the changes are implemented the platform developers also need to “apply” those changes to the templates and components. In our experience this step is one of the most error-prone parts of the entire process. It is super easy to miss just one additional attribute that was added by frontend team or overlook a slightly changed order of HTML elements. And it is also super frustrating for business—especially when frontend developers managed to fix their part, but because of a tiny template mistake there is still a bug in the production website. Version control systems such as Git only remotely address this problem. They certainly make it easier to understand the scope of changes but as the frontend code is already duplicated, the default merging mechanism doesn’t really work—platform developers often end up cherry picking the frontend changes.
First and foremost, we strongly advise you to avoid delivering your project in phases where one supposedly finished part of a system follows another. None of the finished parts can in general be used as a plug-in solution for the other, even under ideal circumstances (which are never the case, believe us) of zero change requests. There is always a need for changes that need to be applied to make the overall product or solution work. On top of that, sequential execution of frontend and backend work results in having an unusable system until the other part is done. Not only does it move any ‘go live’ further into the future, but it also makes it hard to decide on priorities as one part needs to be completed upfront. It is also worth mentioning that working on frontend first and backend second (or vice-versa) is quite far from what any agile working method would suggest. And in case you are considering your project to follow Scrum (or any other agile framework) an approach to separate frontend and backend development is clearly off the table.
So what’s to expect from delivering frontend development first (e.g. with the creation of a static click-dummy) and backend development second:
It is not that creating frontend first is the only problematic approach you can take—preparing backend first also has its very own drawbacks. The most significant of which is the lack of anything visually ready for a very long time. That can be really devastating for business who would like to see the progress of the implementation and is itchy to see ‘something’. Besides that, since larger e-commerce or content management implementations typically take quite some time, it could be hard to decide when exactly to stop working on some nice-to-have features, call the backend ready and move on to the frontend implementation.
Even if you decide that your frontend and backend teams should work together, there are still some organizational challenges to face. First of all, communication overhead between teams. They would need to define a simple and good way of working together. Beyond that our experience suggests another key factor for the successful cooperation of the teams—the teams should be on a similar technical level to easily communicate and understand each other’s problems, proposals and solutions. To make a team setup effective, you want to see a workflow between frontend and backend teams that guarantees that changes can be introduced quickly and that duplication of work is minimised between the teams.
Working on the backend code and on the presentation-layer totally independently (eg. by having two service providers focusing on them) is difficult setup. There may be some benefits of that approach but overall the disadvantages typically by far outweigh those. And you probably want to avoid this approach altogether in order to make the overall outcome of your project better and execution smoother.
We offer you 3 suggestions to guide you towards a successful project. This checklist is intended to help you understand what is important and what is not. Of course feel free to adapt it to your needs, though. We understand that each project is different.
Leave a comment