Nudge Theory for Software Architecture

In 2012, the UK was increasingly worried about low pension savings rates among private sector workers. So the government forced employers to establish “automatic enrollment” for their pension plans.

Employees were automatically entered into their firm’s pension plan, and contributions were taken out of their paycheck each pay period, unless they formally asked to be removed.

The idea was that most people wanted to save for retirement but put off doing so by the fear it would be hard or complicated. Auto enrollment would make saving the default option, and therefore make it easier for employees to do what they wanted to do and push up savings rates.

This is called Nudge Theory. It is about making it easier for people to make a certain decision. Richard Thaler and Cass Sunstein wrote in their book Nudge “By knowing how people think, we can make it easier for them to choose what is best for them, their families and society.”

Has “automatic enrollment” worked? Yes, since 2012, when automatic enrollment was introduced in the UK, active membership in private sector pension plans has jumped from 2.7 million to 7.7 million in 2016.

What does this behavior stuff have to do with software architecture? Maybe more than you think.

Problems with current software development

As large software projects evolve, the development effort involves many different programmers and can span years. This leads to a common phenomenon called architecture erosion: the source code’s actual architecture has diverged from the intended architecture. There are many reasons for this:

Programmers of large systems don’t see the high-level view of the system

New design decisions are introduced that change the intended architecture, but old code is not refactored because of cost restrictions. This means the old code doesn’t comply with the new architecture

With team turnover, tribal knowledge is lost, so new team members are less familiar with the architecture

During the maintenance phase, time and cost pressures force developers to take shortcuts, disregarding the intended architecture

The architecture was never properly communicated to the entire team

If architecture erosion is left unchecked maintainability goes down. Bad dependencies (shortcuts) make code brittle, hard to understand, and hard to maintain. The intended architecture was designed to achieve certain quality goals regarding reliability, security, modifiability, performance, portability, and interoperability. The more erosion that happens to the intended architecture, the more these qualities are negatively affected.

Can a Nudge help?

Software developers are not always inclined to worry about software architecture and maintainability. Rather than just hoping for the best and preparing for the worst, knowing how developers think and applying nudge theory could help persuade any development team to do what is best for the long term maintainability of the software.

The Nudge Unit (U.K.’s Behavioral Insights team) has developed a framework for influencing behavior. To encourage behavior, it must be Easy, Attractive, Social, and Timely (EAST). These four principles can be applied to a software architecture context.

1. Make It Easy

The effort required to monitor software architecture usually discourages developers from attempting it. Often they have to stop using one set of tools and pick up another, resulting in possible delivery delays. This typically leads to the software architecture being neglected for other priorities that are easier to monitor.

Nudging developers to do the right thing when it comes to software architecture has to be easy. This means serving software architecture insights immediately and in the context of their daily work. So if developers want to understand the architectural impact of their code changes on the software system, information should be presented as they perform each build, together with granular insights into which software changes are causing architecture problems.

2. Make It Attractive

According to the Nudge Unit, we are more likely to do something that our attention is drawn toward, including pleasing images, color, and personalization.

A nudge toward better software architecture involves drawing the developer’s attention to a place that they most often frequent, i.e. email, code dashboard, etc. To make it attractive, send their personalized architecture violations (impact) to their preferred communication platform.

3. Make It Social

The Nudge Unit states that we are all embedded in networks and those networks can positively shape our actions. This is true for development organizations as well. Teams typically operate in silos and rarely engage in a collaborative fashion to drive systematic improvements like software architecture.

Development leaders can foster networks to encourage collaborative behaviors to spread across development organizations. For example, they can provide a single collaboration app that integrates all architecture issues and metrics so cross-functional teams have one point where they react, decide, and solve problems together.

4. Make It Timely

Timing makes a big difference in development organizations. Information must be delivered in the context of a developer’s daily workflow. To encourage better behaviors, architecture monitoring must provide developers earlier guidance on architecture impacts - in their world, in their code, and in their terms. If this is done consistently, the behavioral mindset will shift from ignoring architecture problems to driving and sharing improvements in both architecture and design.

Summary

Insights from behavioral science can encourage development teams to make better choices for themselves, their colleagues, and their business. Lattix Architect can help by making architectural impact and insights available after each build. Architecture violations and metrics can also be made available in Lattix Web or other dashboards like SonarQube.