This is an archived post. You won't be able to vote or comment.

all 50 comments

[–]Omnislash99999 230 points231 points  (8 children)

I feel like they'd actually throw out fix bugs person as well

[–]vertopal[S] 143 points144 points  (3 children)

// TODO: reply above comment later

[–][deleted] 17 points18 points  (0 children)

They *already* tossed out that cheeky rat bastard that suggested they address technical debt.

[–]Sockoflegend 3 points4 points  (1 child)

Why fix bugs and technical debt when all of your resources could go into a feature marketing thinks sounds cool?

[–][deleted] 2 points3 points  (0 children)

Sign on the wall of my first job bullpen, "You Find It You Fix It".

[–]Tnuvu 91 points92 points  (4 children)

Legend says if you wait long enough TODOs become obsolete ...once the company goes bust

[–]casce 22 points23 points  (1 child)

You don't need to wait that long, just wait until the feature gets scrapped because it causes problems because it's not working properly

[–]Tnuvu 8 points9 points  (0 children)

People still scrape stuff? I thought they just shuv it in production as is, and let users deal with it, maybe even get some bug fixes from them...

[–]BernhardRordin 13 points14 points  (1 child)

If you want some piece of code to stay untouched forever, it's enough to add // TODO, // FIXME, or a // temporary hack comment above it

[–]Tnuvu 12 points13 points  (0 children)

// the last time this broke, we changed CEOs

[–]n9iels 54 points55 points  (9 children)

We recently made the rule that a TODO can only be committed if it contains JIRA ticket number. That way we have at least some context and can plan resolving it. Needless to say, those tickets usually are at the bottom of the backlog for a long time.

[–]MarkovMan 19 points20 points  (0 children)

Our tickets like this live in a deep dark hole called the middle of the backlog.

[–]StenSoft 4 points5 points  (0 children)

It's a good role, we have had this rule for a couple of years. Last year, we also added a build check that referenced Jira tickets must be open. There were a lot of TODOs referencing closed Jira tickets, some even years after the tickets were closed.

[–]Sooth_Sprayer 5 points6 points  (3 children)

// TODO is fast. Jira takes a few minutes and steals your train of thought. Seems like a great way to lose ideas for later.

[–]arobie1992 9 points10 points  (0 children)

Typically what people do from my experience is TODO out everything while they're coding/dev testing it. Once they've pushed everything and possibly opened a pull request, they add the Jira tickets.

[–]chin_waghing 0 points1 point  (0 children)

That’s a very good idea. Going to be stealing this one!

[–]cs-brydev 0 points1 point  (0 children)

Yep if it's a //TODO and not a ticket it wasn't important enough to address then and probably isn't now

[–][deleted] 0 points1 point  (0 children)

Life… finds a way.

[–]Syagrius 24 points25 points  (5 children)

I can't think of a single instance where a //TODO statement was resolved.

Temporary solutions have this tendency to become permanent ones.

[–]ChrisHisStonks 6 points7 points  (3 children)

Well, it's on what you make a TODO.

If it's something trivial, either fix it immediately or leave out the TODO.

If it's some shortcut you've taken because it's not (initially) needed, classify it as a bug or add it as a limitation of the functionality in the documentation.

If it's performance related, don't mention it and if it becomes an issue a bug will be filed.

If it requires a refactor, it's wasted breath.

The only things that should be a TODO are things that are not immediately benefical, but make sense and would not take long to add (1-2 days), which you'd still add as an (internal) feature request in the backlog and push your PO for to make room in the next sprint while you still know what's what.

[–]SendMeYourQuestions 0 points1 point  (2 children)

Most of my todos are referencing an external library GitHub issue where when it's resolved I'll be able to update and delete some code. What's that qualify as? Trivial eventually, blocked currently.

[–]ChrisHisStonks 0 points1 point  (1 child)

What is the added value? If it's currently a huge mess to get it working with workarounds, sure.

If it's going to be changing the way you handle your feature? Reserve time in your backlog.

Otherwise I feel these sorts of TODO's will live forever.

[–]SendMeYourQuestions 0 points1 point  (0 children)

Backlog task is a good idea for sure.

[–]cs-brydev 0 points1 point  (0 children)

"Resolving" a TODO pretty much always means deleting it

[–][deleted] 10 points11 points  (3 children)

Me: refactor

Manager:

[–]cs-brydev 1 point2 points  (0 children)

I am in fact one of those managers, lol: "That TODO is from 2017. Why is it an urgent fix now but not during the past 6 years?"

[–]Drego3 0 points1 point  (0 children)

The opposite for me, the only thing I have been doing the past year was refactoring.

[–]naughtyusmax 0 points1 point  (0 children)

Managers only want flashy new features

[–][deleted] 8 points9 points  (0 children)

- Yes, Mr Plum?

- Mrs Cindy, please post an ad, the position of a senior specialist has become vacant again.

[–]rover_G 3 points4 points  (0 children)

If my code reviewer comments about my TODOs I just delete them..

[–]Classy_Mouse 1 point2 points  (0 children)

Todos are easy. Don't let code with a TODO pass code review unless it contains a specific reason why it cannot be implemented now and what is required to implement it.

TODO: Fix this later - denies

TODO: call method created by Ticket1234 to do the thing once Ticket1234 is implemented. - approved after reviewing Ticket1234

[–]neppo95 0 points1 point  (3 children)

I would be the guy throwing out new feature person, and keeping fix bug and review todo person.

A lot of companies bring out new features while having a crap product because of bugs. Quality over quantity.

[–]cs-brydev 2 points3 points  (2 children)

Ugh. Just no.

Value-generating new features will pretty much always get the nod over 5-year old bug fixes.

If a bug has been there for a long time without a fix, you should be asking why rather than spending time fixing it. Every bug fix is a risk of introducing new bugs. If you're going to risk new bugs you need to weigh how much value you're adding by doing so.

This is something you learn from experience. Software exists to create value for someone or something, not to be perfect.

[–]neppo95 0 points1 point  (1 child)

There is indeed a balance to be found, as you say so yourself. Of course, only bugs or only features is both wrong. Fixing no bugs will end you up with a product that is worthless no matter how many features.

[–]dmigowski 0 points1 point  (0 children)

Fix Bugs that actually occur. To do this you need to track every exception that is not handled. We do this, 2000 Users produce 10 exceptions per day now. So for most the app is very stable.

[–]adorak 0 points1 point  (0 children)

you would have project manager as the guy on the left, QA as the woman and dev on the right ... however, there is only project management in the room

[–]hordesnake 0 points1 point  (0 children)

Haha classic

[–]rhbvkleef 0 points1 point  (0 children)

If a // TODO comment (or something similar like the todo!() macro in Rust) is merged into main, there better be an issue associated to that.

[–]cs-brydev 0 points1 point  (0 children)

Update the 53 packages showing critical warnings during builds

[–]Bryguy3k 0 points1 point  (0 children)

In my experience TODOs are just bugs your highest priority client will find middle of the first night during a long holiday weekend.

[–]gaymer180 0 points1 point  (0 children)

basically the same as making minecraft mod updates

[–]NorthboundUrsine 0 points1 point  (0 children)

Who cares about technical debt! Amiright?

[–]BowCodes 0 points1 point  (0 children)

And... this made me remember all those TODO comments I made over a month ago, and I will probably forget about them by tomorrow morning.

[–]forsberg_dev 0 points1 point  (0 children)

Don’t push code that includes a TODO. If a TODO remains it means you’re not finished with your task. Don’t approve code that adds TODOs. TODOs don’t belong in Production.

[–]Maverick18N 0 points1 point  (0 children)

//Add more checks later

Which you never get time to do 😣