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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.