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 t...
For further actions, you may consider blocking this person and/or reporting abuse
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.