Curb Your Refactor

Refactoring is a necessity in software development. As engineers, our first attempt at writing new feature code is most likely filled with rats. Then we refactor the code to make it maintainable, readable, faster, and less prone to bugs. These refactoring rules for the three phases of development can help development teams scale the correct code and not break the business.

Consultants do come in many shapes and sizes, so my disclaimer is Uninteractive, my company, is focused on general feature development for early and growth stage startups. These rules may need adjusting for your large scale development operation, although lean focused teams can live by them.

Software projects land in one of three phases – The POC (proof of concept) Phase, the Production Phase, and the Maintenance Phase. Each phase has different requirements to follow for refactoring. By following specific rules in each phase software can meet goals by enforcing code satisfaction and efficient releases.

The POC Phase:

In this phase, a developer or pair of developers are working in a local or isolated environment to prove the software works. There is a distinct red, green, refactor cycle happening.

Always limit code refactoring to “it works” and “other developers will understand this”. Over engineering at this phase burns more development time than any other source of software design. Simply put, make sure “it works” and that’s all.

The Production Phase:

Now that we have proved the code can work, we aim to write production quality code. This phase can trip up many developers with the goal to write the most maintainable, reusable, and DRY code – most developers are wrong. As Rails developers we live by mottos of skinny controllers and fat models – or in the last few years skinny everything. These axioms can blow tight startup budgets out of control.

Duplication of code at this stage of development is perfectly sound, developers should favor descriptive controller action names over pure restful interfaces (follow REST for external APIs), and specs/tests should only be a concern in financial transactions or sensitive information data exchanges. Edge cases that represent 3% of the user base or less should be avoided.

The Maintenance Phase:

The MVP is in production and is starting grow traction. The team can focus on the backlog of issues, data gathering, and bugs. This is the phase of the project where developers make small adjustments in code to match usability and we clean as we go. This is the time of the project when refactoring should be considered in planning meetings and time-boxed.

As refactors are estimated they should be broken into manageable chunks.

For example, “Remove duplication from the API::UsersController actions” and “Break the Account Model switch statement into separate methods”.

These tasks should only be considered if there is a matching update to related feature code. We are most certainly doomed when developers set out to refactor the application without related features or related quantifiable bug fixes. There is no need to refactor quiet code.

Developers can also enforce a stronger test suite in this phase. The “one spec a day habit” for a small teams or individuals can increase coverage very quickly after an MVP is launched.


Large scale refactoring, although very satisfying, is an expensive journey businesses have a hard time sponsoring. Following these guidelines has helped my teams stay focused on shipping code faster while avoiding over-engineering, pre-mature optimizations, and layoffs.

Enjoy the Dance!