Software development is a lot like writing: If you don’t have a quiet, stable work environment it’s hard to get the creative juices flowing.
This puts a damper on DevOps and the transition to continuous, agile application environments because this new way of working is anything but stable and quiet. By eliminating what is now a steady, predictable process of writing code to produce a finished product and replacing it with an endless series of discrete but interconnected processes, the enterprise runs the risk of jeopardizing the very thing that makes developers so valuable: the ability to write good code.
Clearly, however, the situation is not that bad, or else we would have heard howls of complaint coming from the developer community by now. Instead, according to a recent survey by GitLab, Agile is now the most popular methodology, preferred by upwards of 60 percent of software pros, followed by DevOps at 23 percent, and traditional waterfall approaches at 16 percent. Perhaps more interestingly, however, shops that are deemed “high-performing” are more likely to have a strong DevOps culture in place that provides better visibility into the application pipeline and broader collaboration with non-developer contributors.
This means it is essential for the enterprise to get DevOps right, not by simply implementing new tools and new processes but by rethinking the entire software development culture. According to ZDNet’s Mark Samuels, organizations should target DevOps at projects that will benefit most from rapid iteration and dynamic workflows, since this will allow you to build the leadership and management skills needed to take it to the next level. From there, you can expand concepts like project ownership and goal-oriented development to employees, partners and providers.
And of course, there are some things you should not do in the transition to Agile and DevOps, says Tintri Field CTO Matt Geddes. For one thing, don’t think you can maintain the same silo-based work environment. Going forward, all work must proceed in an integrated fashion, using the same formats, styles and other elements. As well, don’t try to plan out the transition to the last detail. The name of the game here is flexibility, so if something isn’t working it should be a simple matter to identify and correct. At the same time, don’t think any of this will be easy, since we are talking about mashing up firmly entrenched cultures and work philosophies.
At the moment, at least, it seems like the data community is embarking on DevOps and Agile more as a leap of faith than as an empirical exercise. The UK Register reports than when Linda Rising, COO of the Hillside Group, asked attendees at the Continuous Lifecycle conference in San Francisco if anyone was running randomized, controlled studies to determine if Agile would improve their current processes, not a single hand went up. This is bad because if you don’t know what you hope to achieve with DevOps, you have no way of gauging success or failure. By framing a hypothesis and subjecting it to small, frequent tests, the enterprise can move beyond endless discussions of what works and what doesn’t to realize steadily improving results.
Software development is an art form, but that doesn’t mean it cannot flourish in an organized, commercial environment. In fact, under a DevOps paradigm, the artistic mindset can be unleashed because a misstep here or there is no longer fatal.
By taking away the fear of failure, DevOps can end up enhancing your developers’ ability to succeed.
Arthur Cole writes about infrastructure for IT Business Edge. Cole has been covering the high-tech media and computing industries for more than 20 years, having served as editor of TV Technology, Video Technology News, Internet News and Multimedia Weekly. His contributions have appeared in Communications Today and Enterprise Networking Planet and as web content for numerous high-tech clients like TwinStrata and Carpathia. Follow Art on Twitter @acole602.
