Leave no legacy code behind
We all complain about Legacy Code. We are limited by the leftovers from previous developers. But are we not guilty ourselves of leaving Legacy Code behind?
When we talk to developers during one of our assessments we are met with almost painful honesty. Software developers will drag out the skeleton from their closet, point to it and say: “This is our problem”. Often his name is Legacy Code. Code that someone inherited, or adopted when it was left in a basket in a back alley. We even see Legacy Code used as an excuse for not doing the right thing. “We can’t automate this, it is Legacy Code”.
So when does code become Legacy Code?
When we hear the term Legacy Code we associate it with old code. Code written in Cobol and running on a mainframe. There are some annoyances around the software architecture, the frameworks, the IDE, the testing or the amount of backwards compatibility issues that arise.
Common to all these is that they make the code harder to change. So we’ll rephrase it as: “Legacy Code is code you are afraid to change”. It does not matter if you wrote the code last week or last year; if you are afraid to change it, it is legacy code.
You have two options regarding your legacy code. If you are no longer developing it, cut any ties to the legacy code base, and feel the burden of responsibility and the daily fear of having to spelunk through archaic code dissipate.
Or you might still be actively developing your legacy codebase. Then you have to transition the Legacy Code into the present.
And no, I’m not saying you should convert your hundreds of thousands of lines of PL/1 into C# and your problems will magically go away.
I’m saying you need to embrace a piece of software that is essential and make sure you can responsibly continue developing and releasing it.
Even if you cannot transition your project to a modern platform, or the task itself seems unsurmountable, do not despair. There are tons of small steps you can take that will make your daily work easier. Automate what you can, especially testing and releasing.
Make a plan for removing the technical debt. If you have a hundred failing tests, don’t try to fix them all at once. Fix one each week. Every single time you are improving your project you will move one step further away from having to maintain legacy code.
All of this becomes especially important when we are helping clients. We tell them to vigorously attack and eliminate their Legacy Code. But we are also producing code. We might write a few scripts, have the code miners deliver a plugin or configure a server. But what happens when our engagement stops? Did we just create Legacy Code at the client we were trying to help?
At Praqma we want to help our customers help themselves. So I solemnly swear the consultant’s oath:
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?
Still relevant or increasingly redundant?
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software.
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Learn how Docker and Kubernetes work and the key benefits they bring. Using real demos, I show how Docker is a great packaging and distribution technology, and how Kubernetes provides a powerful runtime for containerized applications.
Watch this introduction to Docker and Kubernetes at the Trondheim Developer Conference (TDC)
In the world of Agile and DevOps we use many figures, charts and diagrams to argue and reason about our world and how we prioritize and make choices. However, at all levels of the organization, we misuse and misinterpret figures. It’s time to be explicit, measure the right things and act on them. Watch this talk from DevOpsDays Zurich in May 2019.
Watch this talk from DevOpsDays Zurich
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps