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:
The knowledge for the refactoring usually comes from experience on the codebase, experiencing the pain points too often, and new ideas burgeoning on your morning commute. 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?
It should be a requirement that the projects subjected to the hackathon be thoroughly tested. Under no circumstance should previous behavior be broken by the refactor. It's obvious that every codebase should be tested, but it's not always the case in practice.
Pavol mentioned metrics, it might be useful to define some goals to the refactoring: are we refactoring to improve CPU performance? Memory usage? Code clarity? Architecture?
Most codebases that get big enough to warrant refactoring are somewhat professional, often closed-source. What would be the takeaway for participants? I can't see myself signing up to spend a week-end providing free, unrecognized work for another company. One of the fun things of a hackathon is that you work outside of a traditional company setting, openly sharing ideas without having to justify the business value of everything you do. What's in it for the hackers?
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!
"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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.