Truth without love is cruel, and love without truth is foolish. - Sam Leung
Those of you who follow me on Twitter (@foolomon) know that I tweet industry news relating to DevOps and other topics (such as Information Security, IoT, etc.). Based on the sheer number of articles that I come across but do not tweet about, you would be justified in believing that DevOps is still the darling child when it comes to marrying application-based functionality with the business value it should be aligned with.
"What if I told you," Morpheus might ask, "that DevOps is not the panacea you think it is?"
"What, what?" you exclaim. "I thought DevOps is the be-all, end-all of application development! 'Continuous delivery' is the way to go, man!" Bear with me while I explain myself.
Recently, I read an article in Forbes that said something quite profound: "people don’t want to buy a quarter-inch drill bit; they want a quarter-inch hole." DevOps is the drill bit in this analogy; it is the means by which the hole is created, which is represented by the application being deployed to production. The point that I'm trying to make is that, like ITIL was in the 90's, people are putting too much emphasis on DevOps while forgetting that the ultimate goal is to develop an application that does what the users want.
In other words, don't forget to do your homework before writing a single line of code for the upcoming sprint. Otherwise, you'll end up with an application that does everything imaginable except inspiring your users to actually use the application.
As an example, consider my favorite navigation application, Waze. Realize that I use this exclusively for my GPS needs while driving in spite of the fact that I have Google Maps, and the base iOS map application on my phone. However, there are a few things about this application that annoy me to no end, most notably the fact that it will send me through every side street imaginable if that results in an arrival that is 15 seconds faster than it would have been if I stayed on major streets and/or highways.
What they failed to imagine is that each time a driver has to make a turn, the drive becomes a bit more irritating especially when you're already on a perfectly good road heading in the same general direction. Multiple this by 10 turns during a 20 minute drive and you can understand the frustration that people can feel using the application during their drives. Worse, excessive turns makes it much more difficult to remember the route they took, meaning that they have a perpetual dependency on using the application whenever they drive.
When you frustrate your users they start looking for alternatives. For me, that alternative is spending time on Google Maps to familiarize myself with routes to common destinations so that I no longer need to use Waze. For others, it may be to use a different application entirely in spite of the fact that they may arrive a few minutes later than they would have using Waze. Etc.
"So what?" you ask. "You're talking about a free application for my phone." True, but consider the business analog: applications are meant to provide a standardized way of accomplishing a specific task. The moment someone feels the need to deviate from that by not using your application you increase the risk of a lower quality or potentially incorrect result. This can adversely impact your organization's productivity as corrective measures must be taken on a case-by-case basis as well as affect the bottom line because of lost revenue, higher operational costs, etc.
In short, DevOps is a tactical play in that it guides the execution of an application development strategy. What it will not do is determine what those applications should be doing, and it is this activity that is the raison d'être for application development in the first place. Do your homework to make sure you are solving the problem and not simply providing a solution, and you will enjoy success as those applications have a positive impact on your organization's productivity and financial well-being.
Those of you who follow me on Twitter (@foolomon) know that I tweet industry news relating to DevOps and other topics (such as Information Security, IoT, etc.). Based on the sheer number of articles that I come across but do not tweet about, you would be justified in believing that DevOps is still the darling child when it comes to marrying application-based functionality with the business value it should be aligned with."What if I told you," Morpheus might ask, "that DevOps is not the panacea you think it is?"
"What, what?" you exclaim. "I thought DevOps is the be-all, end-all of application development! 'Continuous delivery' is the way to go, man!" Bear with me while I explain myself.
Recently, I read an article in Forbes that said something quite profound: "people don’t want to buy a quarter-inch drill bit; they want a quarter-inch hole." DevOps is the drill bit in this analogy; it is the means by which the hole is created, which is represented by the application being deployed to production. The point that I'm trying to make is that, like ITIL was in the 90's, people are putting too much emphasis on DevOps while forgetting that the ultimate goal is to develop an application that does what the users want.
In other words, don't forget to do your homework before writing a single line of code for the upcoming sprint. Otherwise, you'll end up with an application that does everything imaginable except inspiring your users to actually use the application.
As an example, consider my favorite navigation application, Waze. Realize that I use this exclusively for my GPS needs while driving in spite of the fact that I have Google Maps, and the base iOS map application on my phone. However, there are a few things about this application that annoy me to no end, most notably the fact that it will send me through every side street imaginable if that results in an arrival that is 15 seconds faster than it would have been if I stayed on major streets and/or highways.
What they failed to imagine is that each time a driver has to make a turn, the drive becomes a bit more irritating especially when you're already on a perfectly good road heading in the same general direction. Multiple this by 10 turns during a 20 minute drive and you can understand the frustration that people can feel using the application during their drives. Worse, excessive turns makes it much more difficult to remember the route they took, meaning that they have a perpetual dependency on using the application whenever they drive.
When you frustrate your users they start looking for alternatives. For me, that alternative is spending time on Google Maps to familiarize myself with routes to common destinations so that I no longer need to use Waze. For others, it may be to use a different application entirely in spite of the fact that they may arrive a few minutes later than they would have using Waze. Etc.
"So what?" you ask. "You're talking about a free application for my phone." True, but consider the business analog: applications are meant to provide a standardized way of accomplishing a specific task. The moment someone feels the need to deviate from that by not using your application you increase the risk of a lower quality or potentially incorrect result. This can adversely impact your organization's productivity as corrective measures must be taken on a case-by-case basis as well as affect the bottom line because of lost revenue, higher operational costs, etc.
In short, DevOps is a tactical play in that it guides the execution of an application development strategy. What it will not do is determine what those applications should be doing, and it is this activity that is the raison d'être for application development in the first place. Do your homework to make sure you are solving the problem and not simply providing a solution, and you will enjoy success as those applications have a positive impact on your organization's productivity and financial well-being.