MANAGING A LEGACY APPLICATION DUMPSTER FIRE
July 29th, 2019 by Kevin Pimentel
We’ve all been there. A new project comes in and you are super excited to start it. The coding starts without thinking and the team fails to properly define the scope of the project.
As a developer, what can you do? You just build what the overlords ask you to build. Then comes the dreaded day when the client sees the application and nothing is like they imagined.
The worst part is that the client is changing their mind every 5 seconds and you don’t have any tests written. This means that whenever you implement the new changes, you have no idea if the rest of the application is working.
I’ve been doing a lot of TDD lately for many reasons. But the event that sparked my TDD journey is a project that I’ve been working on for almost two years. The project was poorly scoped, actually, it wasn’t scoped at all.
The project had no tests, which mean that anything new that came up, would cause regression problems. This is a nightmare scenario that I never want to go through again. How do you deal with this kind of regression?
You Write The Code
Because I am lazy by nature, I hate doing things more than once. I am always looking to automate things. Having to fix the same problem over and over drives me crazy. But a project like the one I am describing, has already been built and no tests had ever been written for it. This was a huge mistake.
I pushed for tests at the start, but it fell on deaf ears. I even wrote sample tests of what our test suites could look like, but nothing. I was told there wouldn’t be enough time and I believed it.
Fast Forward a year later, I realize that not having tests is my fault, because I could of written tests. There’s nothing that could have stopped me, other than thinking I wouldn’t of had enough time, I stopped myself.
As developers, it’s our job to be professional and produce code. Nobody stands over our shoulders telling us what we can and can’t write. Most of the time the people that we write applications for think we are doing magical internet voodoo. Truth is, nobody cares how we implement anything. The tests are for us, the developers!
I realized this when I was spending more time trying to fix regression problems than I would have ever spent writing the tests. I had to take a step back to deal with this dumpster fire that I created.
The solution I came up with was simple. From this moment forward, forget everything that happened before. Anything that comes, anything that is new, has to have a test first. No questions asked. That was my first rule. The second rule is if something breaks or the client finds a bug, write a test first, and then fix it.
There really isn’t time to go back and write tests at this point. Going forward however, I can start to move things in the right direction with a little bit of TDD magic.
Write Tests For New Features and Before Fixing Bugs
The book Extreme Programming Explained and Specification By Example have been super helpful. I think I’m woke now. These books really walk you through how to scope out a project, turn those specs into tests, and iterate over development cycles properly. There’s a lot more that is covered but these were my biggest takeaways.
There is a lot of valuable information in those books, but in my opinion, you have to start with improving your own workflow. Another point worth considering is your work environment. If you work with dinosaurs, you can’t push new ideas on them. You better not even mention any buzzwords around them. You will be chased out of the building with pitchforks and fire torches.
I have been successful in implementing TDD in my own workflow and now some of the other developers have started to adopt it. You have to choose one thing and start there. I highly recommend being aware of your environment to figure out what could benefit your team the most.
Writing tests before new features and bug fixes is not something that anyone really has any say over. It’s up to you how you write your code. The more you do it, the faster you’ll get. I am very close now to the point where my tests actually help me code faster because I am following such a tight workflow.
When a new feature is requested, figure out what the client wants. Get involved in the process, ask questions, use examples, don’t dismiss edge cases, and turn every single requirement into a test. If there is even the slightest chance that something is not clear, talk about it. The better you define scope, the more tests you can write, and the more confident you’ll be that all is good in the world. Life is good when you know all the tests are passing.
There are two types of people in the world: those that code, and those that don’t. I said that! Quote me. My name is Kevin and I’m one of the ones that codes.