Maintenance Phase — Continuous Delivery’s Biggest Challenge

If your entire stack is not leveraging the latest sandbox CNCF projects and experimenting with the latest software development methodologies, fire up Blind and look for a new employer. You are not going to grow as an engineer by not using the bleeding edge of technology and not get to speak at conferences. 

Well, this is certainly not true. A lot of what we do as engineers are to pick the best fit of tools for the goals and vision we have for the applications we create. A majority of the time the best fit is not the bleeding edge as maybe a goal we have is maintainability and tried and true works in that case. 

Though for many software engineering roles, we are not coming in at the inception of a project. We have to decompose the decisions that were made years or even decades before our time on a project; welcome to the world of software maintenance. In a prominent piece that has stood the test of time, “Frequently Forgotten Fundamentals about Software Engineering” by Robert Glass, approximately 60% and upwards of costs are dedicated to the maintenance phase. Though maintenance comes in many forms. 

Many Forms of Maintenance 

There are many forms of software maintenance out there. As the initial surge of development slows and our applications/products become more mature, maintenance phases start to kick in. If one was to think of a traditional software maintenance job, a production support engineer / a level 3 support engineer would come to mind. These brave folks are in charge of applications potentially with no active full-time developers on the project; a reflection in the mirror and they actually might be the developer in this situation.  

Level 3 support is just one more well-known form of maintenance. At some point in your career you will be working on the “e” word, an enhancement to an application. Enhancements are a form of maintenance as you are not working on the next major version of an application, most likely a point or minor release per semantic versioning standards. The “ugly” friend of enhancements are bugs. We have gotten a lot better about quality but we can’t predict fully what users will do and security vulnerabilities pop their head in ever so often.   

Garter has a Bimodal Model that splits work into two styles; mode one and mode two. Mode one is more traditional/legacy work focused on keeping the lights on which centers around maintenance phase applications. Mode two is the more experimental work focused on active development and future versions of applications or new from the ground up applications. Mode one focuses on mitigating risk and mode two focuses on trying the unknown. If you find yourself in a mode one situation, the biggest risk is introducing change. 

Biggest Risk, How to Make a Change?

As a technologist, we typically move around to gain new and different skills. The combination of business domain and application stack helps us build skills that are invaluable to our careers.  Like most, working on a brownfield / older project especially one that is on a maintenance phase can seem less exciting than a greenfield project. 

Working on an older project can seem like the project is about to be killed off at some point thus one might not put their best work in for a lasting solution. Though software does not kill software [ok maybe in chaos engineering], the lack of participants/engineers kill software because certain projects are less attractive than others. 

Why one project is less attractive than another could be deployment complexity. For example, let’s say you are working on an older JAVA application. Now JAVA skills are attainable and as a developer, you can figure out how to make a change in the codebase for an enhancement. You can build locally with convention leveraging Ant or Maven/Gradle since those build skills transcends projects. The scary part is how the artifacts/application is deployed; especially scary outside of a development environment. 

A large part of the learning curve is learning knowledge that does not transcend projects e.g tribal knowledge. A programming language transcends projects but the implementation and deployment details are tribal. As a new-ish engineer on a project, imaging you have a build artifact that has just been created, what is the next step? You have to line up environmental properties and application infrastructure getting the artifact ready for a deployment. 

The number of tribal steps will increase especially when you start heading to environments where users are and especially production. Deploying an application in a safe manner not to interrupt users or relying on to get this all done in a maintenance window is where the complexity starts to take off. Now imagine there are not that many people if any who know how to deploy successfully. Word will certainly get out and this is why maintenance phase projects are challenging. Potentially in a break-fix scenario can shortcut some steps but the deployment knowledge is still tribal to even which steps to cut. Now there are groups of engineers that focus on this exact problem, enter DevOps engineers. 

Shifting Challenges for Engineers

Another discipline out there to think about is the rise in DevOps engineering. Stuck between supporting both modes in Gartner’s mode one and mode two, an argument could be made that DevOps engineering teams are in a constant mode two building tooling for supporting mode one and mode two teams. 

DevOps engineering teams fall into the category of engineering efficiency. Newer and greenfield applications certainly by industry standards requires a lot of efficiency, going back to Robert Glass’s piece is a majority of spend is actually on maintenance. The perception that DevOps teams are standing up infrastructure and platforms to support the latest and greatest is valid, though even the fearless DevOps engineer has fear on the legacy applications. 

If the application development/maintenance engineers struggle with baseline information on what having a successful deployment looks like, the DevOps engineers certainly must have the answer? Not necessarily the learning curve applies to everyone and most likely your organization shares the DevOps engineers who have to support multiple teams. The Harness Platform can help solve the deployment divide. 

Harness Bridging the Divide

What if you had a consistent way of deploying applications of varying sizes and technology stacks? Enter the Harness Platform. At Harness, we offer the ability to deploy a wide range of technologies in a manner that matches the risk and change tolerance of the application. 

This means we plug into a variety of infrastructure and with a Harness Workflow / Pipeline build rapidly delivery pipelines for different teams. No matter if you are deploying to Tomcat,  Kubernetes or even Amazon ECS, Harness can deploy to all of these and more with ease. 

A lot of the angst on projects can be reduced by making sure that the tribal knowledge is properly exposed and disseminated. Harness allows for Role-Based Access so developers/maintenance engineers can easily see what steps and rigor are applied to deployments. If your team is pushing full speed into mode two, Harness has your back there too supporting GitOps based deployments.  If you ever had angst around a deployment new or old, sign up for Harness today!

Cheers,

-Ravi