How (Not) To Organise Your Next Web Project

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 ecommerce 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:

• Platforms have their own peculiarities and they are not really frontend (technology)-agnostic,

• Independent frontend developers tend to lack the context in which their code will be used,

• The API between backend and frontend is not clearly defined, usually custom or platform-specific and often subject to change,

• Organisational problems which are pretty standard but often unrealised − like fuzzy responsibility of the parties involved in the project, communication overhead, even differences in coding standards, etc.

Even though platform vendors often try to give you free choice on the use of preferred frontend frameworks (or even on the overall frontend approach − by offering a headless API), it is still a fundamental question how your frontend can be integrated with the platform in the most natural way. Yes, integrating, as in most cases frontend is not only responsible for simply displaying whatever is coming out of the platform of choice. Let me illustrate with a few examples what I mean. Your editorial environment most likely provides mechanisms and tools that enable editors to more or less freely build pages composed of reusable blocks of functionality − and let's agree to call those components. They are often automagically surrounded by additional HTML markup that is required during edit mode. So that may mean the addition of HTML tags, which may break your styles and result in a broken (looking) page! Another example: You are tweaking content in the beautiful visual edit mode provided by the editorial platform. Once you have changed the properties of just one component you would expect that only that part of your web page actually needs to be refreshed (namely: that component). However if your component is ‘dynamic’ and uses JavaScript events to make sure that the page is fully loaded, it simply ends up being displayed incorrectly in edit mode − as the ‘onLoad’ event would not be triggered. All of these problems lead to anything between small glitches to completely unusable pages in edit mode.

Frontend developers can easily translate designs into a seemingly shippable product via a browser (or a good looking click-dummy). 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 ecommerce 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:

• Long rounds of discussions and modifications of frontend code before the backend team confirms the work delivered by the frontend team works in the backend system.

• Troubles with introducing changes − they would need to be processed by both teams, possibly introduced to two completely different code bases (frontend code is duplicated for the click-dummy and actual presentation templates of the content or commerce platform)

• Fuzzy responsibility regarding bugs: In case something is not covered in the static click-dummy but it turns out to be a frontend bug, which team is actually responsible for fixing it? And then of course remember that bug fixes are also changes (see previous point).

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 ecommerce 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.

• Make sure that the service partner responsible for the implementation of your ecommerce or content management solution has a really skilled frontend development team. With skilled, we mean capable of delivering thriving digital customer experiences. One that stays up to date with the latest proven web technologies and has a proven track record of actually implementing those in real life project. If there were no other factors, this should really be your main concern.

• If − for whatever reason − you have two teams working independently on frontend development and platform integration, make sure that your platform and frontend teams are compatible and can in the end work together as one team towards a common goal, as opposed to working as independent parties. There should be no frontend development phase before a backend development phase. The teams should work in parallel, evaluating and integrating their work immediately. It may cost some time to get teams aligned, but it’s still the best you can do in such a setup.

• Make sure that the interface between frontend and backend is well defined and clear for everyone involved in the overall project. This is a main factor when it comes to frontend-backend productivity. Ideally, backend and frontend teams can exchange data that conforms to some kind of agreed schema. This way, backend developers focus on extending the platform and exposing all the data needed to create the user interface by the frontend part of the team. One way of doing so is to use REST or GraphQL as your API. By use of such APIs you immediately gain a lot comparing to the classical HTML-templating approach. Additionally you can also benefit from some handy tools for discovering, documenting and testing APIs—Swagger, Postman or GraphiQL to name just a few.

If you would like to learn more on this topic − better interfacing and therefore cooperating across frontend and backend development in ecommerce and content management projects − stay tuned!