5 Trends From 2016 That Are Changing Software Development

Software development is a moving target. You have to keep your eye on trends in the tech space that haven’t even happened yet just to stay current. Consider what’s happened with augmented reality (AR) in this year alone. If you said you were working on an AR app in 2015, you might have gotten a lot of blank stares or jokes about Google Glass. Then Pokémon GO happened. Like AR, the trends listed below have been building steam for some time, but they’ll be taking off in surprising new directions before the end of 2016. Here’s an overview of what’s coming next and what software developers can do to prepare for it.

1. Linking Application Performance and Business Performance

Application performance management (APM) has grown incredibly sophisticated over the past decade. By 2010, Gartner had defined five dimensions of end-to-end performance for best-in-class software:

1. Monitoring how the end user experiences the application and surfacing discontents.
2. Defining the scope of problems in execution, runtime architecture, and communications.
3. Mapping out user-defined transactions across components (AKA business transaction management).
4. Tools for going deeper into the components identified as sources of the problems.
5. Behavioral learning analytics for patterns of breakdowns and issue forecasting.

Management has been so impressed with the results of reducing Mean Time to Resolution (MTTR) that they want to apply these lessons to reduce the overall Mean Time to Business Awareness (MTBA). Today, highly advanced tools like AppDynamics are doing more than organizing the priorities of development teams. Real-time insights into the customer experience can auto-correlate the relationship between specific performance data and business goals.

At AppSphere 2016, David Wadhwani, President and CEO at AppDynamics, explained it best:

“I can’t say this enough: there are very few times in a person’s career where you’re sitting on a precipice of a change like this. Take advantage of it. Accelerate your careers, redefine your goals. Don’t think of yourselves as IT professionals, think of yourselves as business owners who happen to run the technology as well.”

Ultimately, the application of APM expectations into MTBA measurements is aiding CIOs in understanding how technical choices and priorities impact a business. More than ever, that’s what the CIO is expected to explain to senior managers. At the intersection of technology and finance, the role of the CIO has become the locus for all the most critical data analytics.

2. Application Teams as Human Microservices

The microservices model applies to more than just software. Software tends to match the organizational structure of the design team, just as the switch from waterfall to agile required a restructuring of development teams.

Teams of application developers have always shared out projects like sub-routines or specific software integrations. What’s different in 2016 is that software engineering teams are acting more like independent business units. The microservices model has happened in companies like Google and Amazon, where individual and autonomous “application teams” are organized around specific business objectives. At Google, these application teams include a crucial new role: Site Reliability Engineers (SRE) who combine development and operations skills. As Google’s Ben Treynor defined it, “The SRE is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise, and banking on the fact that these engineers are inherently both predisposed to, and have the ability to, substitute automation for human labor.”

Figure 1: Decoupled applications with autonomous application teams centered around individual business capabilities.

In the year ahead, expect this to spread to more organizations inside and outside of the software industry. You will see more work teams that include their own developers, deployment models, performance engineers, business analysts and product management teams. Like miniature companies within a company, they will operate as autonomous groups responsible for innovation, execution, deployment, application performance monitoring, and business performance monitoring.

In early experiments with this sort of microservices team structure, here are some of the challenges that commonly arise:

• Displaced business priorities. When the microservice goal becomes the team’s primary responsibility, they may pull off course from the overall company strategy, strengthening the argument that more insight into business performance is necessary.
• Microservices that don’t communicate. APIs connecting the functions of microservices can fall between the cracks as teams argue over who is responsible for making sure that they work together. Attaching and detaching microservices from the main functionality of the application is never as easy in practice as it is in theory.
• Struggles with team cohesion. Many developers have developed their skills in isolation and may have difficulty aligning their work habits with a tighter team structure.

In the end, it can only work in the presence of leaders who reinforce communication, collaboration, and success measurements among application teams.

3. Microservices, Containers, and DevOps

One of the most massive shifts in the world of software development hit at the same time as the dot-com bubble. It was the shift from monolithic apps residing on bare metal to distributed applications populating virtual machines. This was partially due to the improved reliability of networked infrastructures. However, it was also a reaction to waterfall development methodologies built on the aging manufacturing model of ideation to coding to testing to production, and then shifting into maintenance mode. This was the period that introduced agile methodologies that made much more sense in the bootstrapping world of software startups.

The point is that we are now headed into another shift that will be at least that pervasive. It has grown out of agile concepts like interactions over processes, minimal viable products and responses over planning. The emerging app-driven world will be defined by the rules of DevOps, where feature development and application performance monitoring have to happen simultaneously. Enterprise software is now a whirling mass of microservices, APIs, and containers in constant communication with each other through the hybrid cloud.

Agile was a powerful framework for development teams, but agile couldn’t keep up with the demands of near perfect uptime and spiraling customer experience expectations. At the same time, it’s clear that developers and testers can have critical inputs into solving operational issues. Everyone suffers when there is internal friction between functionality and security.

When you combine this trend with the AP to BP bridge, the image emerges of a new and comprehensive BizDevOps. It will fold business strategy and analysis into the DevOps formula.

4. Scale as a Service

Popularity can be a problem, as too many startups have discovered. Brooks’ Law, established four decades ago but still disputed, states unequivocally that, “Adding manpower to a late software project makes it later.” Updating Brooks’ Law for the age of enterprise application development means adding warnings like “Rails doesn’t scale,” and “Green dashboards make users see red.”

Going into 2017, watch the boom in vendors supporting services like Elasticsearch to help applications scale without blowing up. To help them get ready to scale, the majority of companies running software are using a mixture of six clouds, both public and private. Three are used for running their applications and another three are used for innovating their next level of services and features.

There are many sides to scaling issues, like bigger nodes vs. more nodes, so scaling up has to be done as a company-wide collaboration. Channel vendors are better positioned to see the bigger picture of inter-related adjustments to security, stability, performance, and cost.

In a turbulent market, which won’t be calming down in the foreseeable future, the ability to scale rapidly is the most essential survival skill.

5. Remote Work and Crowdsourcing

In the past, remote work was merely a geographical extension of work. Managers oversaw projects and directed teams of developers. Instead of the team being in another wing of the building, the team moved to another time zone. The biggest structural change in the relationship was the communication channel from in-person to collaboration tech. In many cases, the application performance monitoring (APM) and Business iQ platform served as the collaboration engine, with voice/video/chat software like Skype or Slack on top.

What’s happening in 2016 is that the concept of crowdsourcing is further abstracting the work from the worker to take advantage of the model’s essential efficiencies. The manager still sets expectations and manages routines, but now the coder’s primary transaction is with automation. They submit code and move on to the next assignment. Managers many not even know the people (or bots) who submitted the code.

A good example is Elastic.co, the 100 percent remote-driven group that created Elasticsearch. The open-source ELK stack (Elasticsearch, Logstash, and Kibana) has built up enough contributors to challenge Splunk for the log analysis market. Flexjobs lists 125 virtual companies running on globally distributed teams so far this year, up from 76 a year ago, and only 26 in 2014.