As Marc Andreessen famously said Software is famously eating the world. It is incorporated into every aspect of our lives, 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 Lifecycle Management (ALM) 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 lifecycle.
For many organizations the perception exists that ALM was driven by vendors. These vendors encouraged a single tools strategy, standardizing on change management, reporting, version control, testing tools and even IDE’s. 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 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 Mac 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 the sometimes the software itself.
And thus is 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:
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 towards making software delivery a truly integrated discipline where management and development work together to efficiently deliver amazing software.