DEV Community

adam klein
adam klein

Posted on

Coverage and courage - the pillars of your codebase

If you're going to run a marathon, you'll pace yourself and carry a bottle of water with you.

Your marathon is the software you build, and we all know good software is one that you can change. Because requirements - they change all the time. Preparing for a software marathon means preparing for continuous changes of requirements, of open source libraries, of the team's structure, and ever changing best practices.

But how do you prepare for change that you can't anticipate? The first ingredient is test coverage. Not just because you need to test the product before you ship a new version, but because you want the confidence to refactor your code, again and again. You want to see a nasty piece of code you didn't even intend to change, and change it along the way without thinking twice. It's like keeping your house tidy, every time you see something small out of place you put it back where it belongs. If you don't - in a few weeks you'll face long and tedious projects of making order, which you will postpone forever.

The second ingredient to this formula is your courage. The courage to rewrite parts of the code even though there's a pressing deadline. The courage to try out new technologies even though it means your code will have 2 ways of doing the same thing for a while. The courage to switch to a different 3rd-party provider because you realized they're not good enough, even though you just spent 2 months integrating with them. The courage to face your non-tech colleagues and stand behind your decisions that serve the long-run, and mid-run.

You have to remember that while other departments might be running sprints, your software department is running a marathon, and don't let the others set your pace for you. If you do, when you are completely out of breath and start to slow down dramatically half way through, you'll be the only one to blame for it.

Sure, not every period of time in a product development lifecycle is the same, but it's your job to make sure there are enough gaps for regrouping, refactoring, and improving the infrastructure.

Top comments (0)