Artificial Intelligence (AI) in the systems development life cycle is currently oriented on automating rote, mundane activities, but the true potential of AI can be uncovered by making it work on creative activities such as software development
Technology vendors and enterprises continuously experiment with new ways of software delivery to ensure the software is bug free, meets the timeline and cost objectives, and can be updated going forward. For this to happen, multiple teams within the software development ecosystem need to collaborate and talk the same language. Enter DevOps.
While the Agile methodology was a meaningful initiative to address the time-to-market aspect of software, it didn’t serve the entire purpose, and release management and operations continued at a sluggish pace. Developers were developing code, but it was rarely delivered into production at the same pace despite “continuous integration” being around for ages. DevOps tries to address this disconnect ensuring tasks such as provisioning, configuration, and security are automated and simple. It attempts to bring different moving parts and teams in an application lifecycle onto the same page, working toward the same target, using the same terminology, and – possibly the most important – working with the same underlying infrastructure.
Opponents think DevOps is a bad idea and much more applicable in startups than enterprises. Not surprisingly, proponents believe this to be a loser’s argument from large organizations and one more excuse not to evolve their archaic systems.
From a software developers’ perspective, DevOps is met with a mixed bag of reactions. Very few developers truly understand it (they are busy coding, their work), some believe in its promises, and some are skeptical. The skepticism comes from the perception that DevOps is trying to shift the onus of managing databases, application servers, and systems to the developers. It is trying to make them what is popularly known as “full stack” developers, superhuman developers who are a data base administrator, a system administrator, a security administrator, and other things all in one.
Many software developers believe that DevOps will add to their already burgeoning overhead, rather than helping them write code that can create great software (I discussed some of this in an earlier blog where I made a case for allowing developers to be more crafty, rather than tied to rote coding). While some senior developers believe it will ensure better time-to-market, reduced cost of quality, and collaboration between teams, they are apprehensive about the role they have to play in this entire game. Though developers do not like raising tickets for everything, and prefer quicker access to infrastructure – which is a key driver for the adoption of cloud services – most developers believe DevOps may be taking things too far for their liking. They also believe that the onus to improve the entire application delivery process is being put on their shoulders (and they’re not at all pleased with that and believe that they are being asked to address IT operations’ laggardness.) Moreover, a lot of them just do not want to work “with” IT operations.
Adding to all this is the typical noise around “culture change.” Of course, anything meaningful requires a culture change. However, viewing DevOps only from a culture perspective is like the proverbial can’t see the wood for the trees. It requires as much investment in tools, collaboration platforms, cloud services, release management solutions, and development platforms.
So how can organizations make the developers see the value of DevOps? Cut through the theoretical knowledge and the puritanical message on culture change. Or, call it something other than DevOps. Make the developers see beyond the confines of their code to how it fits into the broader scheme of things. Help them understand the challenges of IT operations, and how those challenges are impacting the software delivery and hurting the business (of course, IT operations also needs to understand the same about developers). Make developers link DevOps adoption back to business benefits and the importance of them adopting such principles. And, finally, have them have some hard metrics and data to track and analyze the adoption. Do not make it a benign exercise in vanity, but rather something more meaningful and tangible.
The industry should keep experimenting with newer ways of application delivery, and throwing the DevOps baby out with the bathwater may not fit into that mix.
“Are they developers or donkeys?” This rhetorical question, posed to me by one of the technology leaders in a small software firm, pretty much sums up the years-in-the-making mood in the software development world.
Large software vendors to a great extent, and outsourcing providers to a certain extent, are the culprits who have reduced software development to a mechanical job in which developers require more hands than brains. The argument for doing this is the quintessential pursuit of making software development an “engineering” process where things are repeatable, driven by statistics and mathematical rigor rather than creativity.
Advocates of this philosophy believe it is too risky and dangerous to rely on “whimsical coders” to run an organization, and instead require coders who follow processes, structures, and methods. They also purport this approach enables them to “create” many more software developers than if they relied solely rely on “creative developers.” This belief set has resulted into a parallel multi-billion industry of certifications, training, and coaching.
Some of the critics of this approach allege that large software vendors make their developers “robots” to meet their financial and time-to-market commitments. Recognizing this, Pete McBreen’s 2001 book Software Craftsmanship set the ball rolling and questioned this fundamental assumption that making software development an “engineering” process was more valuable than enhancing the craft of the developers. In the same year, The Agile Manifesto also questioned some of the concepts of software engineering and extolled the quality of software developers and their collaboration over tools, processes, and documentation.
Nothing meaningfully changed. As software continued to be used for business efficiency instead of growth, the software development world chose following structure, tools, and frameworks over developers’ fundamental capability to create something meaningful.
However, with digital transformation and the increasing adoption of software across businesses, the value an organization can derive by becoming a “software organization” is many-fold. Software is not only a support for business… in many cases, it has become the business itself. It is the most essential component of both the modern organization and traditional company.
The critical nature of software will push the demand for craftsmanship in software development beyond existing structures and frameworks. Organizations have started to realize that as the impact of software expands to revenue generation and customer delight, they will have limited competitive advantage if all software is made in just one way using the same set of tools and processes. Software built by creative developers is what will drive competitive advantage. And despite the growing adoption of standard packages for back-end operations, most organizations continue to rely on, and will possibly increase adoption of, custom software for client-related activities.
We all understand and appreciate that such drastic change will come in small steps, and the significant required changes may possibly kill some of existing organizations. However, I believe craftsmanship must return in software development to make it an intriguing and interesting field that goes beyond rote copy paste of code to meet some random deadlines.
Of course, not all software will be developed in this manner, and the industry will always require pieces made through structured development. In fact, these may be far more prevalent than “crafted” software. However, technology companies, enterprises with large IT pools, and IT service providers that are unable to realize the importance of making their developers think on feet, and instead dumb them down to achieve self-assigned financial and client objectives, will risk not only losing talent but also market relevance.
©2023 Everest Global, Inc. Privacy Notice Terms of Use Do Not Sell My Information
"*" indicates required fields