Skip to main content

How to get developers to do things your way

It is challenging enough for developers to make their code work. But software has to be more than functional. It has to be secure, accessible, and actually reflect what users want. If you need to get developers to provide something beyond the basics, try these motivational techniques.

I'm not ragging on software developers. It's hard enough to design an application that fulfills its basic functionality goals, is reasonably bug-free, and is delivered on time and on budget.

However, the definition of "it works" has changed. Software needs security built in (surely you don't need examples of recent breaches); it needs a viable user interface that is accessible to a wide range of users; and the application's functionality genuinely needs to reflect what end users and stakeholders need, not just what one boss decrees. The number of complaints we hear—and emit—demonstrates how rarely developers deliver on those goals.

Yet, developers are already under stress, with plenty of barriers that make it difficult to put code into production. How can anyone motivate them to do the right thing—that is, the thing you wish they'd do more of—when it is not part of the existing development process?

 

I asked experienced managers, users, and business people what works and what doesn't. How do you get software developers to apply software security best practices when they design and write code? What encourages them to effectively design for accessibility and better user experiences? What motivates developers to improve their "ask users questions" skills? Here's what the industry professionals told me. (Most identities are obfuscated for privacy reasons.)

Make it a management priority

There are two scenarios here. If you're in a management role—that is, when you say, "Jump!" the developer responds, "Conditional or unconditional?"—then you can get the desired effect by declaring, "From now on, application security is paramount!" Or it does so in the short term. If senior management refuses to acknowledge the impact on development time and thus presses for unrealistic deadlines, expect the programming staff to go back to cutting corners.

The policy has to come from the top, says a system administrator named Rauma. "Otherwise, they will never stick to it. Expect pushback regardless."

The power of persuasion

In the other, less powerful scenario, you work in another department and you need the development staff to do your bidding. Perhaps you need to cajole them to listen better to your application requirements. Maybe the last version of the software confounded users and you're bound and determined to ensure the UI works better this time around.

The most direct way to ensure that you get what you need is to convince management to issue a directive the developers must comply with. But that isn't always possible, and it may not be the best choice in the long run. It's far better to build cross-team relationships so that everyone genuinely wants to work together.

"There are two issues involved: getting the other person to agree that the task ought to be done and getting the other person to agree that the task should take priority," IT consultant Harwell Thrasher says. "We're dealing with a combination of persuasion and motivation." Considering which influence style is most appropriate, he suggests the following: assertive persuasion (presenting the facts and a logical argument); common vision (inspiring others to pursue a shared vision for a better future); participation and trust (asking others to follow your direction because they value and trust you); and rewards and punishments (the carrot-and-stick approach).

For example, appeal to engineers' need for completeness by pointing out that actual bad actors are trying to break their code. That may serve as both a common vision and assertive persuasion. In contrast, one sysadmin's answer—"Write a JIRA [trouble] ticket for each line of insecure code"—certainly is a carrot-and-stick response.

"The key is to figure out what they're motivated by so that the end result is a win-win solution," adds Paula Cizek, chief research officer at consulting firm NOBL. "That's going to look different for everyone, so taking the time to learn and understand their motivations is essential."

Quantify the desired results

Whatever problem you're looking to solve—security, accessibility, stakeholder involvement—it's best to connect metrics to the requirements. You only get what you measure. That is, if it's important for an application to meet a performance requirement (such as "process 15,000 records per hour"), nobody imagines that the software is done until it meets that objective. If you want the software to meet a security standard or pass an accessibility test, that needs to be part of the quality assurance path.

For example, if you want applications to be more accessible, put it in the statement of work as a design requirement, says Johnny, a software developer. "Make accessibility a mantra for the fundamentals of how your software is developed," he says. "Have the testing department specifically test for accessibility. Do not consider anything production-ready until those tests are passed." And, he adds, discipline anyone who doesn't fall in line.

 

Learning to identify good metrics and what to measure is another issue, though.

Sometimes, requiring the adoption of a standard industry practice can provide quantifiable measurements. In regard to security, for instance, infosec pro Irena recommends ongoing education, constant reminders ("the OWASP Top 10 is a good tool for this"), and peer design and code reviews.

Learn empathy

One long-term approach is to encourage genuine collaboration between the development staff and your own. In that case, both departments can learn from each other.

"Cross-functional reading groups and working groups can be really effective," says Beth. "I started thinking about security when my company picked one engineer from each team who was the 'security working group' member and filled out a security audit for their team. Then we hung out (with snacks provided) and learned about best practices together that could address outstanding problems."

Never turn down an opportunity for consciousness-raising. Or snacks.

"Many engineers will do things if they need to be done and no one else is doing them," Beth points out. "So establishing the expectation that this is a thing that needs to get done but we've been ignoring it, and then treating it like a 'special project,' will cause a lot of engineers to go learn about it."

Also, Cizek suggests, build empathy by connecting developers to the people who are affected by their work. For example, Facebook held "2G Tuesdays" where the company simulated a slower Internet connection to let staff see how pages load in the developing world.

Help developers ask better questions

One empathy test is how developers conduct user interviews. However, stakeholders don't always know what they want or what they (or end users) need.

That makes it even more important to encourage software developers to ask better questions, listen well, and learn to read tea leaves—which is not an easy task. "Most programmers are really bad at relating to non-programmers," says Matthew. "Developers tend to see the world in on/off or 1/0. Stakeholders see the world in, 'Well, most of the time we want this....'"

One way to go about it is to ask stakeholders what they want to accomplish (for example, "track product deliveries"). Direct them away from suggesting solutions ("The database should…") and toward describing the problems they need to solve.

Ask stakeholders to tell you how their systems work and describe the current workflow. "If I didn't get questions within a certain period of time, I started asking my own," says James Schweitzer, former senior principal software engineer at Raytheon, who worked primarily with control systems, crypto, and signal processing. "The questions would be along the lines of 'How did you decide to…?' or 'What's your approach?' Guidance documentation always contains at least one ambiguity. That's always a good topic for questions."

Security is part of the process

Empathy goes just so far. Everyone has been banging the drum exhorting developers to "bake in security" for at least 20 years, but that hasn't kept vulnerable applications from making their way into production.

Before you ask developers to add something else to their workflow, first contemplate: Are they the right people to own this?

"Practicing code security is something that management needs to push down from above," explains one sysadmin. "The best that we can do is to follow best practices on our end to minimize risk," such as isolating unsafe code and setting up firewalls.

"You don't give them the choice," advises infosec professional Jeff. "Spell out the process to be followed." And don't assume that developers know everything about security; that's what the company's security team is for. The security team—which should enforce the software security practices—needs support from upper management. "If the security team has no one backing them, they are just full of wind and filling a void," Jeff says.

Several security professionals suggest that the organization hire experts in that field rather than ask developers to stay up to date. Set up a standardized release system with mandatory security audits and quality assurance checks before software is released, says computer scientist Alex Mueller. "Obviously, one needs dedicated people in the organization for this; the software developers are usually not the right fit for this role."

The security team needs to enforce proper security considerations for software development, agrees Jeff, based on current industry security standards, and guide developers regarding which ones are appropriate to the task.

Alternatively, you can do your best to make the developers quiver in their boots. One software architect recommends telling the programming staff about data breaches in the news. He adds, make a point of reminding them "that having your resume include companies with data breaches is bad for career progression." And that doesn't need to be coy: "I usually post those in the company Slack and go, 'It would suck to have that bad mark, but that only happens to people who don't write secure code.'"

Raise accessibility awareness

Some application functions do need to be designed in from the start, such as optimizing user experience and accessibility features.

Again, use a combination of process and education. "Implement automatic checks as blockers to deployment" as a first step, says UI expert Connie. The second step is to raise awareness and grassroots implementation via frequent informative communication. And, she adds, show that these topics are valued by management.

"Developers have a different relationship to software than their end users," says Misha. "To most people, software is a means to an end; to a developer it is an end in itself. So understand that and don't try to change it, for one thing."

Instead, says Misha, use a "show don't tell" approach. "I find that observing user research is really useful and eye-opening for everyone on the team," she says. "Keep coming back to what you learned in the research when discussing the product. And on the next project, engage them in creating user-centered hypotheses and task flows from the start."

Another way is to watch actual behavior. Sit with customer support for an hour and watch the process, suggests one sysadmin.

That can raise the developer's awareness in more than application requirement terms. "As a software engineer who wasn't very invested in the user experience when I first started, the thing that changed my outlook was seeing people try to use my software without me being there to explain to them how it worked," says team lead Anca. "Perhaps you can invite the developers to observe a user test? Even when I was an arrogant young know-it-all, it was emotionally devastating to see that my work was causing people to feel frustrated."

Ultimately, the best way to get developers to do what you want is to convince them that it benefits them—and their work—to do so.

Getting developers to listen: Lessons for leaders

  • Motivate by executive fiat. It's hard for anyone to say no to the boss.
  • If it's important, make sure that it's part of the test suite. Software cannot launch if it doesn't pass the test.
  • Persuade developers that adding the "new thing" benefits them personally, whether it's their egos or avoiding a career-limiting move.
  • Consider whether the task should be given to specialists in a review process. They are in a position to develop deep subject matter expertise.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.