Hacker News Reader

Comment by once_inc | Hacker News Reader

My previous employer used to plan "express checkout" weeks for developers. In between two larger projects, you'd get the chance to spend two weeks doing nothing other than picking low-hanging fruits off the bug-tracker tree.

It worked miracles, with minor-but-irritating bugs getting solved much faster, and with features for niche groups getting implemented as opposed to laying in wait for a bigger project it would thematically fit in.

Some devs even went out of their way to spend those two weeks on a single, irritating, deeply-rooted bug that nobody in their right mind would even want to fix.

View on HN

I've been at a few orgs that do this kind of thing and most have found it valuable - but it is a double edged sword that will need to be managed. For the time not specifically allocated to "fixing bugs" or "removing tech debt" or whatever choice of phrasing there is, the rest of the time there is a (misguided) implicit pressure to permit quality to drop to make gains in delivery because "we have time allocated to fix things like this" - so the moral of this post is it is possibly more important to keep encouraging maintenance of quality throughout your team's cycle, and not let maintenance be ring fenced!

Yeah, our "gap sprints" end up just working on stuff we didn't get done in the regular sprints. Really nothing different.

That works as long as there's no scoring system, no leaderboard and won't affect your performance review at the end of the year, or you'll just create another version of the Cobra Effect.

"The British government, concerned about the number of venomous cobras in Delhi, offered a bounty for every dead cobra. Initially, this was a successful strategy; large numbers of snakes were killed for the reward. Eventually, however, enterprising people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped. When cobra breeders set their now-worthless snakes free, the wild cobra population further increased."

https://en.wikipedia.org/wiki/Perverse_incentive

I know the story, but still find myself smiling everytime I read it.

> Hacktoberfest is an October-long celebration to promote contributions to the free and open-source software communities. In 2020, participants were encouraged to submit four or more pull requests to any public free or open-source (FOS) repository, with a free "Hacktoberfest 2020" T-shirt for the first 75,000 participants to do so. The free T-shirts caused thousands of frivolous pull requests on FOS projects. A large volume of pull requests made by users amounted to counterproductive changes to code, including: changing project names from "My Project" to "My Awesome Project"; changing bullet points to dashes; and in some cases, even breaking working code

It's a good resume filter though. "Hacktoberfest" => No Hire.

This is a ridiculous idea; if anything goes on to show how random hiring processes are imho. Check the contributions obviously but why flat out say "you joined a hackathon we don't like your kind here"?

This is a great idea and every company should set time aside for it. Not just a "oh we reserve X percent for issues", but a dedicated, "nothing on the todo list" period.

I worked at a place once where my favorite time was at the end of the year; most people were off on vacation but they needed a skeleton crew in case of issues. This was when we did tons of small bugfixes, improvements and refactorings, and honestly that's the best part of the job IMO. Screw building features and adding customer value, just let me do janitorial jobs :D

I have a theory that if you did away with the "big projects" and just maintained a clean environment you would find that most of the big projects suddenly become "oh yeah, we could do that with a couple of scripts now"

It's amazing what we live with in tech debt and what a clean environment would enable.

I was on a team that did three week sprints separated by a one week “do whatever you want” while the manager and tech lead planned the next three week sprint. I lived for those weeks! It was great for fixing bugs, refactoring for the hell of it, or adding new internal features. I probably learned the most during those one weeks, because someone would inevitably refactor something and we would all learn from the approach. Sometimes we didn’t even commit the new code, but would steal successful patterns for future code.

Sometimes, we would “invent” something novel and truly impressive that would open doors to future features that were previously impossible.

How awful were your main sprints that were foisted on your without you being involved in the planning?

We were involved in the planning, but the tech lead and manager were dealing with the details and priorities from stakeholders. So the last/first couple of days were usually us giving feedback on their plan. But it actually worked out quite well. We were a small team (4-5 of us total), so there was constant communication and no dictation, but someone had to order the cards around and keep things organized.

We do that after every sprint and it does work wonders. So 2 or 3 weeks sprint then a week of this, sprint again, a week on the list, which can also be features - we maintain some 40 internal projects and not all projects get (or need) a sprint.

I personally like it because the issues are more diverse and I get to pick. For example, my last task was something a colleague complained about in a reporting tool that was also bothering me and I also got to learn something new

Love this idea. How many total weeks of the year be spent in such a way on average?

It varied, but it was often 2 weeks after a 3-6 month project. Not a lot, but enough to really make a dent in backlogs.

That's a great idea. Sounds like they cared about the product long term.

Reply on news.ycombinator.com