During my job as a frontend developer for Solid State Group, I've seen several scenarios which block work for specific areas of the development team. Be it design, markup/style implementation, technical frontend or backend, at one point or another they reach a point where they are relying on someone to complete some work before they can get on with their task.
Over the past few years, I've been quite interested (rather selfishly) in finding as many ways as possible to get to a place all these people can work happily in parallel as much as possible without being ground down to a halt.
To set the scene, here are some examples of the sorts of things I'm referring to:
Here are some solutions...
Pact, by itself, is a contract testing tool. A consumer of data (in this case the frontend) defines what it wants from a data provider and publishes this to a broker before doing any work. Developers of the provider (in this case the API) reference this and use it to develop against.
Both frontend and backend developers can work against this single source of truth once it is defined, using it as a basis to discuss changes if they arise. Expanding on Pact a bit, we've built on top of it to automatically generate a local mock server on the frontend.
As a result, often we've found that we can develop a large chunk of an application only then to flip the switch from localhost to a development API to start integration testing. During this time both the frontend and backend developers aren't waiting for each other to complete bits of work before knowing where they stand.
Before Pact
After Pact!
A frontend developer can use the Pact JSON as a mock server, this is really useful for developing when you can't reach the API or when endpoints don't exist/haven't been changed yet. This is much better than working against a static JSON variable because when the API is ready you can simply switch the endpoint from localhost.
Recently in our web and mobile projects, we've kept a page that contains every single component the application presents. In particular, I've found this works really well with React and React Native.
Non-technical developers on the design side can implement the designs without getting bogged down in application logic, while technical developers have a reference to what markup to use when implementing new features.
Not only this, but it often means that any bugs or tweaks to do with appearance can be worked on once in a single place rather than tracking down a certain screen or workflow.
Before style guide pages
After style guide pages!
Non-technical developers have a simple page that isn't bloated by code to implement the markup for their designs.
Being able to efficiently test workflows and clear down the data saves a lot of time and prevents the need from relying on backend developers to clear down databases.
Before teardown endpoints
After teardown endpoints!
Having covered this in a bit more detail in my post here, this idea is more about developers not being throttled by the complexity of a large app.
I must have spent days on old projects constantly registering as a new user to test out onboarding or messing around with integrations with hardware just to get to the part I'm working on.
The solution is to build your app in a way that it can be manipulated into certain states via a constants file, or better yet a remotely configured feature flags
Before simulation flags
After simulation flags
I won't go into how much developers should rely on boilerplate magic after all every project is different. In our case, we build 10s of projects per year, so having a standardised setup for development has been crucial.
Previously, I'd seen developers sit together for half a day or more getting people set up and aware of the oddities of a particular project. Having a base layout project makes developers new on a project feel like they've worked on it before.
If you are interested, here's a lite example of what our frontend project is based on.
Before Base layouts
After Base layouts!
Hopefully, people have found some of these tips useful! Let me know what practices you use to help work better together.