As a backend developer, I recently worked on a big feature for our web app. The feature required a massive change on our backend code, a big change on our frontend and multiple migrations. You know what I’m talking about, it was one of those things that developers are afraid of.
But I gained a lot from that project. Not only did we deliver a kick-ass feature, but I learned the importance of teamwork and patience when developing. With those two and the right tools and technologies, you can deliver your feature quickly and efficiently.
Here are a few more things I learned. I hope these tips will be helpful to you, whether you’re developing a giant feature or one that requires only a small change in your code.
1. Plan so you understand development requirements
The process of development starts way before you start coding, with planning. After the product manager decides what needs to be developed, R&D needs to understand the cost - how many days (or weeks) of development the feature will take, how many people will be needed and which APIs are required.
To do that, the product manager needs to conduct at least three “grooming” sessions with backend, frontend and QA leaders. The grooming sessions start with the product manager presenting the product flow and requirements.
Since no one wants to read a lot of text (except the awesome readers of this article), the product manager should prepare mockups. They don’t have to be designed or colorful, but they do need to show the team what the feature looks like in his or her vision. During our grooming sessions, we used Balsamiq, which lets you create screen sketches for how the product is supposed to look, feel and work.
Editing screen sketches on Balsamiq
After the initial presentation, the sessions should include a lot of going back and forth - asking questions, checking for answers, examining compliance, etc., until everyone is satisfied and understands what the feature requires from them and from others. This is the time and place for frontend, backend and QA to give their opinion about the schedule, to alert and flag any potential problems in development or extreme use cases. It’s the role of product to answer questions and change the product flow and requirements, until there are no rejections from R&D.
Afterwards, the frontend and backend leaders need to create a feature development plan - they should sit and determine which data they need to transform the product vision into a real thing. Or in other words, which APIs are required for each flow or button, how long each step is supposed to take, including buffers and the order of development. APIs are the agreed “contract” between the development teams. After determining the contract terms, each team can proceed individually.
I recommend you write your APIs in Swagger, which turns YAML files into detailed HTML pages with all the APIs.
This plan needs to be transparent to everyone working on the project. In fact, it’s even better if each project participant can add and describe scenarios. Tools like TestLink and Atlassian do just that. Then, when the code is ready, developers can go over the list and see everything is covered.
We will need to stick to this schedule later on, especially when new demands unrelated to the feature come in, like fixing bugs. Sticking to this plan is the best way to distinguish the wheat from the chaff of the development process.
2. Start writing automations ASAP
After planning, we want everyone to start working - not only the backend. To do that, the backend can prepare mocks, either through outsourcing services like JSON servers which show inputs and outputs, or by writing dummy code.
I mentioned earlier that we used Swagger to write APIs. We also used it to to generate a server in NodeJS/Python, like this:
Generating a JSON Server through Swagger
From this moment on, frontend can begin writing and building screens and QA can start writing API automated testing, by using tools like JMeter. At this point, frontend and QA have the response codes and response bodies, they know which features to put where, which APIs they need and how to use them. QA also knows which data they’re missing, like field names and field data. Sure, the backend code isn’t ready yet and all of the automated exams will return “red” instead of “green”, but the main issue is making sure everyone is as prepared as possible.
This includes load and performance testing. You can use open-source tools like Apache JMeter™, which is enhanced by BlazeMeter. By uploading our test script into, configuring the number of virtual users and ramp-up time, determining geo-locations to test from and analyzing KPIs to determine trends and the health of our system, we can ensure our product is delivered to our customers without crashing. This is also true about sending code to QA - developers should test their code themselves and ensure that when they commit their code, it works 99.9% of the time.
By starting automations as soon as possible, you can minimize future bottlenecks in the development process.
3. Ensure the team communicates and works together
Like I said before, teamwork is the most basic requirement when creating a new feature. This is because new questions arise during development and because requirements change. Therefore, everyone in the team needs to be in sync all the time, from the product manager and the designer to the developers and QA.
Open communication lines are crucial because everyone is working on the same product at the same time, but each developer or QA should be working on a different part of the product and on different functionalities. Communication ensures each person’s work is compatible with the rest of the team’s work. This saves time, prevents frustration and redundancy and ensures maximum professionalism.
To make sure everyone knew what was happening, we used Slack and opened a dedicated channel for the creation of this feature. We also had daily (short!) standups where we discussed what we have and what is missing.
Opening a Slack channel
Communication also includes team and assignment management. JIRA, our primary issue tracking tool, offers Kanban-style, Scrum and fully customizable boards, which show the progress of each development task, including the developer assigned to it, and his or her exact status or phase. This helps you understand what other people are working on, and just as importantly - where people are stuck. If you can, get everyone to work in an open-space and put a large screen in the middle of it - this lets you be in sync at all times.
We used JIRA to open and manage bugs as well. This was helpful when multiple QAs found the same bug. It’s important to carefully choose which tickets are opened and put them under one epic, so everyone stays focused.
Another important aspect of communication is ensuring everyone uses the same terminology. English or your local language, sure, but sometimes people might use the same term to describe different things, or different terms to describe the same things. To prevent mixups that could waste your time, make sure everyone is on the same page. For example, do you say “system admin” or “<name (ex. BlazeMeter)> admin”?
4. Work on the same development environments
It’s important that everyone works on identical development environments and even on the same version of the tools and libraries. Otherwise, it could cause an (in)compatibility mess, including a lot of unnecessary back and forth and even might cause bugs to pop up. This environment needs to be as similar as possible to production, but only on a smaller scale.
Now look at the feature that came out of all that work, here. I’m so grateful I had the opportunity to work on it with an awesome team.
I hope these best practices help you the next time you develop a new feature. Don’t forget to keep going agile after development and delivery, by running tests in a Continuous Environment like Jenkins for every commit. BlazeMeter works with Jenkins, ensuring you can load test in the cloud and analyze your data while shifting left. You can also use different APM tools, like New Relic, AppDynamics and CA APM to alert you about errors before QA, which saves time.
This article was originally published on devops.com at this link.
You might also find these useful:
Interested in writing for our Blog? Send us a pitch!