In today’s Agile world, software updates and build features are able to be promoted to production with the snap of a finger. It is still imperative to understand what should be used to determine if a feature in a build is worthy of production. Just because we can throw some code out there doesn’t mean we always should! The SDLC is a cyclical repeating process; its axle must always be stakeholder input.
There have been conflicting viewpoints in software development practices over the last five years. Do we ship right to production, get user feedback, and apply fixes? Or, do we spend the time creating an automated testing audit through a QA channel then to production? In any case, what happens if functionally within our code is rock solid but the product feature change is unwanted and produces a poor user experience?
An excellent example of this is what we are looking at from the social media space race. The ultimate goal of these titans’ mobile applications is to maximize ad revenue and data collection while not having an adverse effect on the end-user experience. How quickly have we forgotten about #ripvine… how about this gross overestimation and failure? We could potentially see the same thing for the Snapchat IPO as well. There has been a definite uptick in use of the Facebook and Instagram story feature. I for one am waiting on LinkedIn to get on the wagon too. Could being on the leading edge be Snapchat’s demise?
As users are moving away and not continuing to do updates, the biggest risk to the company’s operation is security. Users can potentially miss critical security patches when they want to hold onto the old UI.
But why not just give the users what they want? In this day in age, everything should be under source control one way or another. Reverting back to legacy code should be simple, right? This is not always the case. By applying better ALM practices, QA helps team-manage these types of situations.
Application Lifecycle Management is the process in which an organization can monitor a product from the idea’s conception to its end of life. This methodology breaks it down by three major parallel work units:
Governance- Team responsible for business-use case development, determining if a feature is to be implemented, and making decisions based on the Operation unit’s work.
Development- Team responsible for code development, software testing, and applying code updates which have been approved and passed down from Governance unit.
Operations- Team responsible for deploying code updates from Development unit, application performance monitoring, and reporting user metrics.
By applying cohesion across these teams and ALM best practices we can determine if a feature is worthy of production and if it will effect the bottom line. Using Agile and DevOps principles we assure build features are easily implemented or unimplemented throughout the SDLC.