DEV Community

Cover image for Resist the ‘quick fix’

Resist the ‘quick fix’

Nick Holden on March 12, 2018

I often come across problems that, on the surface, seem like they’d be “quick fixes.” Maybe it’s a bug that could be resolved by tweaking one varia...
Collapse
 
ben profile image
Ben Halpern

Where, specifically does the To-do list live? Who sees it? And what's an example to-do?

Good post, would love some examples.

Collapse
 
nholden profile image
Nick Holden

Good questions! The to-do list should live somewhere that all relevant stakeholders can see it and chime in. That's going to vary based on the team, project, and task, but in general, the more visibility the better.

A to-do should at least have a brief description of the task and some way of tracking who's working on it. As people discuss and begin work on the to-do, it can be helpful to add supporting links, screenshots, demo videos, etc. There are plenty of tools that do this well -- I've enjoyed working with Basecamp and Trello.

I wouldn't worry about trying to conform to any particular format, especially when you're just getting started. I think to-dos should be about getting context out of individual's brains into a shared space rather than adding unnecessary process or bureaucracy.

Collapse
 
ben profile image
Ben Halpern

Thanks!

Collapse
 
buinauskas profile image
Evaldas Buinauskas

Teams that are working with Microsoft stack, often use VSTS to manage their backlog. 🙂

Collapse
 
perttisoomann profile image
Pert Soomann

"Couldn't you just ..." ha ha. Uuum, how 'bout no?!

But being serious again, something that has worked well for me recently is trying to solve multiple known similar issues/feature request with one over-arching bigger solution, instead of quick fix of very small and specific edge case.

Could be wrong, but I feel I first heard about this approach from Downwell game-dev blog, but also seems to work well for bigger business webapps :)

Collapse
 
nholden profile image
Nick Holden

For sure! It's great when a general solution can address multiple issues at once. I've also found that those types of approaches can lead to more resilient and easier-to-follow applications than a patchwork of quick fixes.

Collapse
 
perttisoomann profile image
Pert Soomann

It's of course easy to go crazy and re-write stuff just for the sake of it, but it really feels like good practice, as dev, you're not writing throw-away code and can be proud of your nice neat code, and business also gets a re-usable feature that now can grow and solve even further problems, probably much quicker in the long run than doing 10x quick fixes.

I like the part about easier-to-follow app, I might sneak that into my next board presentation as additional benefit :P

Collapse
 
hdennen profile image
Harry Dennen

"but through discussing the to-do, I’ve learned that a change wasn’t necessary after all." Chesterton's Fence is a handy principle regarding this.

Collapse
 
hilaberger92 profile image
Hila Berger

Great article!
I agree, writing a public to-do really improves the communication inside the team.
Also, that way, if you are stuck - you can get help from team members that saw your code and might have interesting ideas to share.

Collapse
 
beginagain profile image
Todd Hogarth

At my workplace we use github enterprise where we log our TODOs as issues. This kicks off a discussion which may lead to it being worked on.

Collapse
 
nholden profile image
Nick Holden

Nice! I recently moved to a new team that uses GitHub issues heavily. It's been a little painful retraining my muscle memory that's so used to working in Basecamp, but the goal is the same: getting to-dos out in the open.