Step 24: Don’t be Afraid to Break Things~ Mike Lewis

This is the 24th Step towards gaining the Programming Enlightenment series. If you didn’t learn the 23rd Step, read it.

Whether it be in life or as a software developer, we need to move away from our comfort zone. We should be moving away from of safety harbor, otherwise we wouldn’t never know our amazing islands.

In Software industry we meet a project where the codebase is precarious at best. We see a lot of what a Sick-Code is. The code is Rigid, Fragile and Non-Reusable.

Why break-code?

There are thousands of ways things can go wrong with our application at any given time — most of the user related. You will never know what’s wrong with your code if you don’t break it.

We shouldn’t not be afraid to break the code. If something gets broken in the process it’d be temporary. We can always come back to refactor some more to make it more error free.

Everyone has this paralyzing fear that if you start to inject changes to a stable codebase it might bring some more bugs. But, because of that fear we add more patches and the code will have lot of code smells ultimately making it rigid, fragile and non-reusable code.

A stitch in times save nine”. We should invest some time now rather than later. It always bears fruit.

As a developer, it’d be a great time to understand the code.

How to break code?

We can start to break the code, by maintaining a healthy test case base. If we have a good test cases, then we can easily step on top those test cases and confidently break code.

Test-Driven Development is what will give us the ease of breaking code. We start with failure and slowly try to correct it as we start breaking the code.

Learn to Refactor and handling Legacy Code.

Be a strict follower of Boy-Scout rule (Step 8).

Follow SOLID principle to make the code modular.

Think like a QA tester.

Tweet from Bill Sempf

TL;DR Maintain a healthy test coverage and start breaking the code with the knowledge of refactoring and how to handle legacy code.