How about a refactorthon?

Refactoring.

It’s one of those concepts most of us talk about a lot more than we actually get to do. Software budgets rarely grant stretches of time for developers to reshape code without any visible outcome. No client is willing to pay for that.

Instead, we have to figure out ways to refactor-while-we-write. Refactor early and refactor often-that’s the answer! Yet, still, software cruft is as certain as death and taxes. Theory usually meets harsh reality. Getting the damned thing to work before the next deadline usually usurps writing elegant code. All those little tradeoffs in favor of now manifest as the tangled, ambiguous, directionless mess of code we have to maintain later.

And besides, you might not know what the proper refactoring ought to be until the codebase smells enough. Early-and-often refactorings can make for a pretty set of shrubs on the front lawn, but you might step back one day and realize what you really needed were a set of lawn chairs on the back patio.

At some point in a codebase’s life, enough cruft builds up where the gears of progress begin to stall. We can plod onwards, pushing our way through the molasses of technical debt. Or, by some miracle, attempt to convince our stakeholders that we’ve squeezed all we could out of V1 and it's due time to rebuild it all over again. Neither feels like an optimal approach.

A handful of times in my career, I’ve felt the overwhelming urge for the “big refactoring.” I’ve thrown caution to the wind and barged my way into the IDE after hours and on weekends-whatever chunk of time would allow me to completely focus on my personal vendetta against the offending codebase. A covert operation is sometimes the only viable approach.

There is always a moment during these sessions where the investment finally pays off. At some point, you know the hardest work is behind you and the fruits of your labor lie directly in front of you. The final Tetris piece falls into place. The abscess can be obliterated. The smell is gone. The code no longer runs on black magic.

That moment, for me, is the most satisfying part of programming. I know many others feel the same way. In my experience, a monumental amount of good can be done in an intense weekend session of refactoring. It’s a shame that this often has to happen under the proverbial cover of night.

Here’s a new idea: A refactorthon.

Hackathons are usually geared toward the rapid development of nascent ideas, with groups of people that just met, on an overabundance of caffeine and pizza, coding for a day or two on new technologies without formal breaks. Oh you know… just the kind of environment conducive to code in critical need of a refactoring.

Our industry bends too far forward these days. The carrot dangled in front of us is to build whatever is new, and to do it fast. But, the more critical need in programming today isn’t yet another single-page mashup app using the JavaScript framework flavor-of-the-week sitting on top of the newest structureless database. Rather, it should be to take all the technical stuff that’s proven useful for society and make sure it continues to stay useful for the long run.

So, what if, instead, we turned the idea on its head? What if we assembled groups of programmers together for a weekend to refactor existing production code?

On day one, each participant would receive the same real-world, working codebase and a thorough explanation of what it does. Perhaps, the development team who actively works on the codebase could explain where the biggest pain points live and be on-hand to answer questions (Sure, depending on the codebase, there could be NDAs and other papers to sign but stay with me for a moment).

Individuals would then have time to review the codebase. At some point, teams would form and work would begin solely focused on refactoring. No new feature additions. No ideas to make the app more marketable. The room’s energy would be entirely devoted to improving the working codebase, head to toe. In a couple days, every team would be able to significantly improve code in some way.

At the end of the refactorthon, teams would present what they refactored. Why did they choose a certain approach? How did it improve the codebase? How much code were they able to remove? What makes the code more readable now? The active development team could choose the refactorthon winner.

Imagine how many great ideas and discussions would circle a room when a few dozen bright folks all tackle the same objective for two days-better code. Maybe a refactorthon is the counterweight our industry needs to align what’s cool with what’s desperately needed right now.

Originally published at https://dev.to on January 1, 2017.