By David Grieser
You hear the loud-pitched fire alarm going off, alerting you of smoke… It could be real fire! Fortunately in most cases it’s just over-cooked food.
Now imagine burning food every week, day, meal, or hour! The battery in your fire alarm might just give up. Or you, tired of the annoying and incessant sound, might just pull the plug!
While we’re quick to pull the plug on fire alarms, why have we let them become the driving force for software development?
Pssh… you might be think that you aren’t firefighting all the time, but rather just “maintaining software”.
Where do you draw the line?
If users have random issues with the software and just clearing the cache or tweaking some data in the database fixes it, then you might be firefighting.
When you know you have deal with this issue for another user, or maybe even the user before, then you might be firefighting.
You deployed a new feature, but have made multiple releases, each involving tweaks to make it work right, then you might be firefighting.
At this point, you’re probably asking yourself, “How do I get out of this situation?”
Or if you aren’t at the stage yet, you will be eventually. Ultimately it will impact your productivity and happiness as a developer.
Lets go back to the small gains we want to make and have control over.
Most developers when they get into a job, have to maintain some existing application. After all it’s a great way to learn the code base. However, you won’t be tempted to change any of the code, because if you do, you’ll have to own up to it when it breaks. Hence you get thrust into firefighting mode from day one!
We can break free from this cycle, but it will take a small investment right now.
As you have issues come up, begin to write tests for them. Yes I know this is easier said than done, because management might be breathing down our neck to ship, and you might have a rather large code base to contend with.
This is why I’m suggested a small investment.
Follow these 3 simple steps the next time you fix a bug:
Write a test that fails to ensure the problem exists. This is basically reproducing the bug.
Write a test to validate existing functionality of the problem area. Make sure to break the existing code to validate your test isn’t a false positive.
Change the code to get your test to pass!
Eventually, you’ll need to repeat Step 2 for other paths of your existing code base. It will take some time depending on the size of your code base. But if you can start to practice writing tests as a habit, then you’ll make progress sooner than you realize!
As you continue to write tests you’ll build a regression test suite that will that will get you closer to total test coverage of the codebase.
The benefit of doing this is that as you move forward, you will not have to think that something broke from your latest fix, because your tests already inform you of this.
It might take awhile to put out all these small little fires, but since you aren’t just blowing on them till they are embers to come back, you’ll have more time to develop code, rather than just maintain it!
About the Author
David Grieser is a computer scientist graduate from the South Dakota School of Mines and Technology, where he enjoyed tutoring other students!
Post graduation he became the lead developer at BizeeBee. Most recently he has been working with C# and .NET using MVC 4 with a focus of BDD (behavior driven development) and TDD (test driven development).
David loves teaching people how to write clean code and gaining the confidence they need to pursue their own projects. He also cares a lot about users, and building with a focus on user experience. With David you’ll learn to look at the big picture of any problem, and come up with simple and elegant solutions, rather than re-inventing the wheel.
