Nebbia Technology

23 April 2018

5 ways to increase productivity in cross-functional dev teams

With the craze over building Single Page Applications (SPAs), companies have joined the movement and hired armies of front-end engineers with/without experience in back-end technologies.

To accommodate the new talent, many of these companies have built cross-functional teams. Simply put, it’s a team of front-end, back-end engineers, and other disciplines working together to deliver a product. In general, front-end engineers work on the SPA features while the back-end engineers develop the supporting Web APIs.

The challenges

Although products are higher quality and teams more Agile, productivity sometimes grinds to a halt.

An issue in the development server hosting the back-end APIs could be a showstopper for front-end productivity. Updates to back-end services have long turn-around times because the developers have to deploy their own code to the test environments. Sometimes front-end developers also have to dig through unfamiliar code to know how an API works.

So, it’s evident that feedback loops could be shortened, the human factor could be removed, and better tools could be chosen.

There are five main ways in which productivity can be increased.

1. Continuous deployment

Although deploying code to a test environment might not take a long time, 5-10 minutes, 2 or 3 times a day adds up. This also doesn’t take into account the context switching developers have to do in order to deploy the application. Mistakes happen and manual deployments don’t always go smoothly.

One way to effectively increase productivity is to automate deployments, with a deployment pipeline that builds and deploys the code after it’s checked into the source control system. By having this level of automation, any member of the team can request deployments of their features without having to bother a fellow teammate to deploy the application.

There are various tools out there to do continuous integration and deployment. At Nebbia, we like to use VSTS to build, deploy, and manage our release pipelines. For most projects, our applications are deployed automatically to a development environment soon after the code is committed to the repository and reviewed by others.

2. Self-documenting web APIs

Engineers often lose track of what endpoints are available. With large applications especially, there are other team members interested in how an API is defined, including QA analysts, Security Engineers, and even stakeholders. One way to communicate to everyone how these APIs are defined is through documentation. But having to do this while in the development cycle can quickly become counter-productive.

There are several packages that automatically document an API with minimal developer involvement. Swagger UI is a very popular open source project that lets anyone visualize an API and its resources. There are endless integrations with Swagger with numerous programming languages. A live example of Swagger documenting a sample API can be found here.

3. Create front-end prototypes with mocked data

While tools like Swagger can help expedite some of the guesswork in how an API works without digging into the code, there will be times where fellow teammates responsible for back-end work are busy working on something else.

There are numerous JavaScript playground sites out there like JS Bin, CodePen, JS Fiddle, and Plunker, which host and run front-end code so that engineers can develop iteratively. They’re great for figuring out how a feature might work and get feedback from fellow developers or even stakeholders.

By using good design principles and abstracting away API calls into their own components, front-end prototypes can be developed against mocked data that resides in JSON files. For instance, if your app needs an API endpoint to manage customers, you could abstract API calls to instead return data from a customer JSON file. Frameworks like Angular make this abstraction particularly easy.

There are number of data mocking tools out there. For generating raw JSON files with some context on the type of data (eg, first name, last name), for example, take a look at Mockaroo.

4. Effortlessly run APIs in any environment

Today, SPA development is quick and iterative when developing against a hosted API. However, there might be situations where the development environment cannot be updated or it might conflict with other features being developed.

It’s a good idea, therefore, to ensure the back-end is executable in any OS, so that front-end engineers can develop locally. Especially with the micro-services movement, back-end stacks can be written in many languages like .NET, Java, JavaScript, and Ruby, and it could be problematic to set up complicated development environments.

New container technologies also make cross-sharing code especially easy, but it can be expensive to implement in the beginning. This makes it important to find out what works best for your team and your organization: container technology or tool standardization.

Until recently, .NET stacks were limited to the Windows environment. With the advent of ASP.NET Core and Kestrel, ASP.NET APIs can be run on any OS with very little effort. With the craze over VS Code as a lightweight IDE, it can quickly be tailored to run front-end or back-end code on any OS.

5. Use a feature branch strategy

A ‘feature branch’ strategy can be used against many source control systems to manage code checked in against a feature, and have less impact on other features being developed. Using this approach, a developer can create a branch of the source code repository whenever he or she starts working on a feature, and a subset of the development team can work together to complete a feature without affecting other development efforts.

Martin Fowler gives a high-level explanation on this strategy on his blog. At Nebbia, we like to follow the feature branch strategy using Git.

Lastly, Atlassian gives a little more detail on how to implement this strategy using Git as the version control system.

At Nebbia, we like to implement these strategies to develop meaningful applications for our clients. Feel free to reach out to us for help in setting up your deployment pipeline with some other DevOps practices or if you simply need some guidance on how to streamline the development process for your own application.

If you need help with DevOps consulting, custom software development, Azure, or training, get in touch.