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.
Top comments (12)
I think this kind of thing makes so much more sense than hackathons in just about every way. It encourages truly positive habits that are, as you described, easy to let fall off without peer reinforcement. Refactoring is also probably the part of programming where peer involvement can have the greatest impact. The nascent stage of a project kind of seems like the worst time to get so many people working together. It's often a better outcome with just one or two people hacking away at something in relative solidarity at the beginning.
When time is scarce, it also seems to make a lot more sense to hack on existing projects where the first hours are not going to all go towards configuring Webpack. Most of the best time will be spent on the most important part—writing maintainable code.
Hey Ben,
Great point -- "The nascent stage of a project kind of seems like the worst time to get so many people working together. " Agreed. Devs need time to formulate their own opinions and approach especially when there's nothing running yet.
I think peer involvement is particularly important in refactoring as a way of helping each other validate their approach. Also, like "normal" pair programming, it's a way to keep each other on track at the task-at-hand. It's really easy to get into rabbit holes as you refactor and suddenly have a whole bunch of things in a half-refactored state. The social aspect can mitigate that.
Oh yeah, definitely. One frustration I run into with pair programming on feature building is that we often hit a wall where there is some research that needs to happen or some issue that is more comfortably worked out in solitude (depends on your personality, of course). With efforts of pure refactoring, everything is already "done" in a sense, so there is less likely to be that progress wall that has lead me towards the tendency breaking off and working through issues on our own.
Love the idea! I agree that a week-end's worth of binge-coding can completely turn a codebase on its head.
There are a few questions this raises but I'm sure we can work through it:
I think a great middle ground that would address at least the first and the last problem, would be to organize these days inside a company. The same way some companies do "innovation days" or "days of code" and let team members work on alternative ideas to the project, there could be "refactor days" when you finally let the devs run wild and rewrite their most hated piece of code. I know I would look forward to these days every year!
Great points Charles!
Addressing a few:
"How do we communicate enough for the hack team to know what to work upon but still have free reign to come up with great ideas?"
I may get some disagreements here, but I think there are actually a lot of refactoring approaches that are preferable to be done by people more new to the code. For one thing, naming comes to mind. It's a lot harder for me if I'm so comfortable with the domain to assess whether my classes, properties, etc. are expressive as they could be. I might automatically look at a class like "Notifier" and go..."oh yeah that's the thing responsible for sending out Slack messages", whereas a fresh set of eyes might look at the name more critically.
You also make a great point about professional codebases -- there are certainly diminishing returns if you have, say, a massive 20-year old codebase and you have a room full of fresh devs for 2 days. Perhaps there's a right "type" of codebase where a refactorthon works best -- something that isn't brand spanking new but maybe in an early release cycle or an MVP state. Something that's far enough along to have built some instantly recognizable cruft, but isn't so far along where you'd have to spend weeks ramping up.
As far as what's in it, I think the mere exercise of examining and rehabbing code is most of "the fun". I think everyone would learn a ton in the journey moreso than the end result.
I think more professional codebases will wind up being open source in the future. If your product is not the code itself, and it rarely is, there is little sense in closing it off. In the short term, it still makes practical sense to keep things closed, but I think things will trend towards openness.
We plan to make this website, dev.to, open source, and I'd be game to try something like this even before we get the open source project out the door. I've been itching to get some total outsiders to look at some of my decisions and criticize, ask good questions, and help us clean up the gunk.
That's an excellent idea, you just inspired me ;)
I am thinking starting small (in a limited group of people) to try this out.
Please have all of my ugly source code that you want 😝
This is a good idea. I think that testing needs to be discussed though. The cost of refactoring comes from regression testing existing functionality. I think we would need refactorthons followed by testathons. You could argue that figuring out the regression testing strategy and following through is part of the overall refactorthon. I'd agree about that. Either way, it's something I'd love to try.
One of the best courses I took in college was the well named "Software Engineering 2". "Software Engineering 1" divided everyone into teams of 5 to work on a 10 week project.
The professors took the worst project submitted in Software Engineering 1 and had everyone break out into teams of 5 again to refactor that project. It was an incredible learning experience.
I agree with the other comments that this is much more useful than a hackathon. The conversations around the work will be much deeper with an existing system than with something from scratch. It's also much more applicable to our daily lives since we all spend much more time maintaining and building on top of software than we do starting projects from scratch.
Let me know if you want help setting one of these up!
Beekey -
Great to hear how your college courses involved refactoring in their curriculum. Taking something from one course and extending it to the next is a really clever idea. I wonder if refactoring is more commonly taught in most computer science curriculums nowadays (I hope so).
This looks like an amazing idea. We have done things like Bugathon, where the entire team bashes the app for an hour or so to find any defects. Refactorathon looks promising.