Software is famously eating the world. It is incorporated into every aspect of our lives and is used by everyone. Regardless of industry, software provides an opportunity to organizations of all sizes.

For the majority of organizations, their ability to compete and differentiate is directly tied to the apps that run, sell and integrate their business. But software is not a commodity that is mined or drilled for, it is instead a commodity invented by software developers. Yes, software is a team sport, and any finished application or product is touched by many people on its way from idea to implementation. But the ultimate creators are software engineers.

In fact, the majority of modern development approaches, such as agile, put software engineers center-stage. Agile methods empower software engineers to work directly with customers, business stakeholders and marketing organizations. Jeffrey Hammond, Forrester analyst, describes developers as an “untapped resource for innovation and business opportunity.” But, for many managers, this idea strikes fear into their hearts.

Managers think of software development like any key process in their business, as one that should be managed and dictated. They believe that discipline, control and reporting must be applied to the practice of software development. Developer freedom and empowerment are easily confused with anarchy and chaos, and, for most organizations, software delivery projects are already late, confusing and, worst of all, under-deliver on their promise.

Historically, managers have looked to application life-cycle management to provide process control, reporting and traceability. ALM is described as the application of business discipline to the practice of software engineering, the solution to application chaos. ALM provides managers with the ability to control the application throughout its life cycle.  

For many organizations, the perception exists that ALM was driven by vendors. These vendors encouraged a single-tool strategy, standardizing on change management, reporting, version-control, testing tools and even IDEs. But as organizations introduced standardization initiatives, developers seemed in parallel to be adopting new tools. This was not always just to cause trouble, but instead was in direct response to business need.

Standardization is a great idea, but it is difficult for any one tool platform to innovate at the same frequency as the industry. Disruptions such as mobile, cloud and the open Web continue to change the fabric of development, thus making tool selection more difficult. Developers who historically would have used one programming language and one set of tools now look to multiple development languages, tools and techniques. The age of Developer Populism is upon us, where developers are like other craftsman bringing their own tools into the workplace.
#!
Developer Populism, a special form of tech populism, describes how practitioners are bringing in technology from home and the open-source community to better serve them in their job. The example often cited are workers bringing their Macs into the office even though the company gave them a PC. Developers not only bring in different machines, but also the tools for building software and sometimes the software itself.

And there’s the rub: Software innovation is crucial for business opportunity and value, but to do it requires empowered, innovative software engineers. Management practices encourage process and control over empowerment. ALM, the application of management discipline to the practice of software engineering is, for many, the embodiment of anti-empowerment and choice. But it does not need to be that way!

Instead of concentrating on one tool to “bind them all,” ALM vendors need to instead focus on enabling the value streams of multiple tool adoptions. To do this, they need to embrace tool variety, while not forgetting the principles and practices of ALM. It should not be forgotten that the increased use of good business management to software development will help everyone. This leads to the creation of a different sort of ALM, an ALM that:

• Concentrates on federation of development systems of record instead of forcing each practitioner to use one tool. Consider the value stream of software delivery to be heterogeneous in nature, with many tools providing their own system of record. Each system of record must provide its information in a way that allows it to be unifying into one definition of the truth about the application and projects.  
• Adopts open standards for integration instead of imposing a set of vendor-appointed standards. By applying standards such as REST and the de facto standards provided by open-source tools, the ALM strategy will be better placed for success.  
• Provides transparency across tools instead of focusing on one vendor’s data without any regard for the other vendors in the development stack. This requires tools to integrate data from other tools in their own context. For example, bugs may be discovered in the testing tools, but then used in backlog reports for the project management tool and then resolved in the IDE.
• Allows for workflow to be delegated to different tools instead of expecting one tool to manage the whole value chain. Expect that each tool will come with its own workflow. For example, a defect’s state will be managed by each tool that uses it, but each tool will be responsible for checking with the other tools to ensure that it has not violated the aggregated workflow.
• Integrates the whole life cycle instead of focusing on just development. By not applying a single-tool approach, it is possible to consider the whole value stream, not just the development or software development life cycle. Portfolio Management and operations can be included. ALM becomes the enabler to the emerging DevOps and agile demand management trends.

Developer Populism is happening with or without management’s blessing, but that does not mean that you have to lose out on the promise of ALM. Traceability, reporting and workflow can still be served, but in a different way. By concentrating on integrating the development flow, organizations can better position ALM as a unifying, rather than disruptive, technology that allows software developers and their teams to work together in the tools of their choosing. By combining ALM and Developer Populism, perhaps we are on the first step toward making software delivery a truly integrated discipline, where management and development work together to efficiently deliver amazing software.

Dave West, who led the development of the Rational Unified Process at IBM Rational, is Chief Product Officer at Tasktop.