Posts Tagged ‘code’

Constant Re-factoring Over Design

January 27, 2011

When the waterfall methodology ruled the streets of IT for so long, developers gave so much weight for design. Everything must be generic enough to satisfy every single possible need from the business in the future without major code changes. However, as the old saying goes: Jack of all trades, and a master of none. I have had many discussions with colleagues over the past over how much weight to put into the design phase. Being the IT leader in my start-up, I understand how quickly business requirements change, and even worse, how they may actually become something contradictory to what they initially set out to address. That is why as a successful developer you must always opt out for an agile development approach where you introduce changes gradually. Don’t over-think the design to handle anticipated future changes in requirements. Just do what’s enough to handle the problem at hand.

That being said, there are a few rules to follow. First, just because you are only addressing the problem at hand, that does not mean you should write bad code. You should not introduce hacks or shortcuts just because you are trying to fix the problem of today. Staying away from creating generic implementation that can satisfy every single possible turn and twist of future business requirements does not mean we should write code that will only work for today! We must make sure as developers that we write good code that is capable of change. We need to introduce the proper loose coupling when needed. It is an art to write code somewhere between over-engineering and just plain bad code.

The second thing to keep in mind is to not be afraid of having to re-factor your code. If you are adding more and more incremental changes, and then you reach a point where you feel like your base may not have been created to support the direction where you are going right now with your incremental changes, don’t be afraid to stop, and re-factor. As a matter of fact, having to constantly re-factor your code is a healthy sign that you did not over-engineer to begin with. It is also a good thing in terms of forcing you to re-evaluate some of the legacy ways that you implemented to handle things a few months or years ago. Things change, and having to re-factor may provide an opportunity to clean up some of those old legacy bad habits that were introduced initially.

That said, make sure that you are not constantly re-factoring with every single new incremental change. This means that you are never creating good enough code that is sustainable to begin with if you are always re-factoring. Re-factoring should only be needed after many incremental changes to the same base code to the point where you feel like you are starting to create many one-off cases. Only then you need to go back and re-factor to ensure more of a smooth transition of your data flow throughout the system while supporting the latest business requirements.

Having to constantly re-factor is not a free pass. It comes with responsibility. You must have the proper unit testing in place to ensure that problems reported in the past do not show up again just because you have re-factored your code. This transition should be transparent to your end user. You also have to make sure that your re-factoring is also done incrementally. Just because you have identified that you need to re-factor part of the code, that does not mean it is a good idea to start a code re-factoring revolution and you have to re-factor the entire application. Introduce re-factoring incrementally as well.

To summarize, always write incremental code that is necessary to satisfy the current business requirements. Don’t over-engineer and never over-think about possible future turns and twists. Continue to unit test and add more and more unit tests. When you get to a point where you feel like your base code is becoming a little shaky with your incremental changes, start re-factoring, and make sure your unit tests continue to run successfully. Finally, make sure you introduce your re-factoring incrementally as well so the impact is negligible. The most important thing to remember is to never over-engineer, and to never be afraid of going back to re-factor frequently.