“A frog boiling in hot water.”
“‘Ball of spaghetti’ messes.”
“Death.”
Eric Miller, a staff engineer, has quite a few animated metaphors for ignored non-functional requirements. Still, he has a point: if left unattended, NFRs can cause major problems in future code deployments.
Miller and his team at church management software Church Community Builder consider NFRs to be “first-class citizens.” To start, traditional NFRs, like security and performance, are considered essential to development work, Miller said. They are built into the development process and require consensus before deploying features to production. Other NFRs are attached to functioning requirements so when those tickets are being addressed, those NFRs are as well.
But they are called non-functional for a reason. Sometimes NFRs are in conflict with functional requirements or aren’t relevant to the current project. Jason Waldrip, CTO at staffing solution company GigSmart, said engineers must put themselves in the shoes of stakeholders to ask, “Should I care?” If an extra week now will save time and money down the road, the answer is yes.
“Our focus often goes to what is right in front of us, but decisions made today in the code can impact how we work for months and years to come,” Waldrip said.
CTO Jason Waldrip compares NFRs to maintenance on a car. Sure, the bare minimum is cheap, but if you want the car to last, a little investment goes a long way. At staffing solution company GigSmart, he explains to stakeholders why addressing NFRs will result in better performance and productivity in the long run.
Why is it important to prioritize non-functional requirements throughout the development process?
Non-functional requirements can be a tough sell to stakeholders outside of the development team and even sometimes to those in software development.
Throughout my career, I have on more than one occasion been described as a “code idealist,” due to how strongly I push for non-functional requirements to be given consideration and prioritized. Organizations are always looking to deliver value as fast and cost-effectively as possible, and when deadlines come looming NFRs are oftentimes the first place to look for cuts.
In order to get buy-in and approval on NFRs as a software engineer, it is imperative to be able to put yourself in the shoes of various stakeholders and be able to answer the question of “Why do I care?” The answers to this question can vary by department, but in general, it boils down to advocating for long-term “ilities” across an organization.
A common theme across them is a long-term benefit to the company. “Is buying a week now worth costing us a month down the road?” That is often the question I ask my team when we are discussing our roadmap and plans for the year. It is hard to do. Our focus often goes to what is right in front of us, but decisions made today in the code can impact how we work for months and years to come.
How do you prioritize each non-functional requirement? Who else is involved in this process?
Focusing on NFRs should not be conflated with just working on things to make software engineers' lives easier but, instead, like taking your car to the shop for service. Sure, you can do the bare minimum and get out of there as quickly as possible with the lowest cost, and if you're planning on getting rid of the car in a year that's probably a fine strategy. But if you're planning on keeping the car for generations and want to avoid a massive overhaul or failure at some point, regular maintenance of critical components and services are absolutely recommended and required to do so. NFRs can and should be thought of in the same way.
Decisions made today in the code can impact how we work for months and years to come.”
In prioritizing NFRs, there can sometimes be trade-offs in which certain attributes either enhance or degrade others. How do you inform your decisions around what to prioritize and when?
Now the analogy of a car is helpful, but it takes more than just knowing that it's “recommended” oftentimes to convince people to invest in maintenance or upgrades. You have to put it in terms they can understand. So just like it is clear to everyone why having tires with enough tread to stop in a short amount of time is critical, it is important for software engineers to be able to explain how NFRs will result in confidence that the product is stable, future speed of production will be high and users will have a positive experience. If you can do this then you can confidently get support from your software engineer peers, product team members, finance and leadership team that working on NFRs is the right thing to do.
Eric Miller and his team hold weekly standups to address NFRs and upcoming work that might need special attention. While NFRs like security and performance are baked into the development process, NFRs like scalability and maintainability will get a consensus from the group on their priority in the current project at Church Community Builder.
Why is it important to prioritize non-functional requirements throughout the development process?
Ignoring non-functional requirements is like slowly boiling a frog: if you ignore them too long, you end up in dangerously hot water. NFRs can often feel like they get in the way of functional progress, especially on smaller projects, but ignoring them leads to those “ball of spaghetti” messes no one wants to deal with.
One of the key NFRs we’ve focused on the past few years has been the performance of our software. A few years back, we began a code refactor of our monolith. The refactoring effort was desperately needed because our code base had become unwieldy and it was difficult to modify without breaking something.
Unfortunately, as we began the months-long process of refactoring, all of our testing and goals were functional in nature, meaning if the software continued to function the same throughout the refactor, we shipped it. However, the performance was problematic. We tested on small datasets, not considering the fact that many of our customers’ data footprints had grown significantly since the code was written.
We unwittingly introduced a large amount of inefficient queries as we attempted to accommodate greater reuse throughout the code base. Our server processing time skyrocketed, and we began to see intermittent outages as particular hosts would get overwhelmed by multiple simultaneous, long-running requests. We weren’t really aware of many of the issues until our customers started complaining about them. As the complaints grew, we decided to deploy a free trial of New Relic to gain insight into our production performance. Within hours, we saw with clarity just how inefficient things had become. It was a good reminder that performance requirements and constraints needed to be a first-class citizen alongside functional requirements in our development process.
We believe that some NFRs, like security and performance, are essential to all development work.”
How do you prioritize each non-functional requirement? Who else is involved in this process?
We believe that some NFRs, like security and performance, are essential to all development work. We’ve built them into our processes and require consensus before deploying a feature to production. For instance, we have performance tracking in place on our development playgrounds that give real-time performance feedback to developers as they work on a feature. These metrics are consolidated for peer review and require buy-in from both our development and infrastructure teams before work goes to production. Additionally, secure coding practices are typically handled through standards and practices built into our development methodology and code reviews.
Other NFRs are not always relevant to every project we work on. To address those, we hold weekly standups with our site reliability engineers and our feature reliability developers to discuss upcoming work that may require special attention. Topics of conversation usually include issues of scalability, availability, privacy and maintainability from a cross-discipline perspective.
Additionally, requirements around maintainability are handled at quarterly or annual planning meetings. We solicit feedback from stakeholders, estimate the work, prioritize it and decide what we’re going to get done for the next year on a quarterly basis.
In prioritizing NFRs, there can sometimes be trade-offs in which certain attributes either enhance or degrade others. How do you inform your decisions around what to prioritize and when?
When we have NFRs in conflict, we’ll typically get product management, software engineering and our SRE group in a room to investigate the trade-offs in detail. We look for false dichotomies, challenge preconceived notions, seek agreement on non-negotiables, detail risks, offer compromises and discuss solutions. With the right people in the room, a satisfactory solution always seems to present itself. We give higher priority to issues of security, and we favor solutions that meet the more immediate needs. We inconvenience ourselves rather than the customer, and we take a hard look at cost-to-value ratios.
