Shitlist Driven Development (2016) • Hacker News Board

Re: Shitlist Driven Development (2016)

#51

Post by Robin_Message » Tue, Dec 15, 2020, 3:53 PM UTC

remote_phone wrote: post #49

dhosek wrote: post #25

If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.

That’s because you don’t understand what deprecated means. Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”

I've always understood Deprecated to mean "This works, but we don't want you to use it in new code, and we plan/hope to remove it in the future."

Re: Shitlist Driven Development (2016)

#52

Post by TeeWEE » Tue, Dec 15, 2020, 3:57 PM UTC

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"...

Never use profanity in your code, nor in your comments. Lets keep things professional.

Re: Shitlist Driven Development (2016)

#53

Post by ritchiea » Tue, Dec 15, 2020, 3:59 PM UTC

scott_s wrote: post #43

andruc wrote: post #42

Earlier quoted context omitted.

Is supporting the article's position frowned upon?

No. But when it's not explicitly mentioned as support, it can appear as an implicit contradiction to readers. We also want the discussion about an article to build on what the article proposes, and explicitly tying comments to the article help with that.

Agreed. There's been a lot more "commenting without reading the article" here recently than in the past. So when someone comments on an article without anything in the comment that refers back to the article and merely offers the exact advice that was in the article without further analysis or insight:

1. That gives the appearance of a user who hasn't read the article

2. Even if the user did read the article I'm not sure what their comment adds to discussion of the article. For comparison, imagine participating in a conversation with a few friends in real life, friend X says "It's a good idea to write tests for your code," then friend Y replies "It's a good idea to write tests for your code." Usually the way people discuss things is to reply or offer addendums to the original idea. It's not a rule, it's just good conversation.

Re: Shitlist Driven Development (2016)

#54

Post by alextheparrot » Tue, Dec 15, 2020, 4:01 PM UTC

Robin_Message wrote: post #51

remote_phone wrote: post #49

Earlier quoted context omitted.

That’s because you don’t understand what deprecated means. Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”

I've always understood Deprecated to mean "This works, but we don't want you to use it in new code, and we plan/hope to remove it in the future."

This is the practical usage, it is really language dependent, though.

C++/Wikipedia uses the definition of the original poster, while Java's @Deprecated annotation literally has a `forRemoval` boolean value attached. Personally, I am used to how it is used in semantic versioning where it is just a helpful hint for what the next release's breaking changes may be while introducing the migration behavior if possible in this release. This allows for clients to incrementally migrate instead of making it all or nothing.

Re: Shitlist Driven Development (2016)

#55

Post by adewinter » Tue, Dec 15, 2020, 4:05 PM UTC

TeeWEE wrote: post #52

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.

If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle.

Why not use profanity in code? We're all adults.

Re: Shitlist Driven Development (2016)

#56

Post by rightbyte » Tue, Dec 15, 2020, 4:06 PM UTC

chapium wrote: post #26

Love the concept, hate the name. To me this seems like the recycle bin concept. Allow the code to exist temporarily, but encourage permanent deletion. Perhaps a better name could be a "screamlist" or "needstochange" list.

Todo list?

All arbritary rules like this just makes the process a mess.

Also the same people doing the shitlist will most likely be the dug in senior ones responsible for all the shit code being there in the first place and include the wrong things.

Re: Shitlist Driven Development (2016)

#57

Post by mcv » Tue, Dec 15, 2020, 4:08 PM UTC

Even in a single-team project, I've ran into the problem that I'm refactoring some old code while others keep adding to it. Some way to have to cause failing tests sounds like a great idea.

Re: Shitlist Driven Development (2016)

#58

Post by raverbashing » Tue, Dec 15, 2020, 4:08 PM UTC

TeeWEE wrote: post #52

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.

You would need a "deprecated light warn" and a "deprecated heavy warn" modes as well. Then you can go step by step

Re: Shitlist Driven Development (2016)

#59

Post by Spivak » Tue, Dec 15, 2020, 4:09 PM UTC

TeeWEE wrote: post #52

Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.

I feel like the profanity rule could go either way. If your team has a culture of casual profanity then go for it. Something like "listen here you little shit" can be lighthearted and funny in the right context. Profanity is a smoke test for anger which is the thing you need to actually avoid.

Re: Shitlist Driven Development (2016)

#60

Post by adewinter » Tue, Dec 15, 2020, 4:10 PM UTC

notabul wrote: post #24

JBorrow wrote: post #17

Earlier quoted context omitted.

I don't understand what this has to do with the article or the previous comment at all.

The article is about deprecating and taking functionality out of use. My point is that deprecation is by its very nature going to hurt something that isn’t prepared for its demise. There is no good way to do it. There are only less bad ways to do it.

At this point if you/your company is still using Flash I find it hard to sympathize with you. How did the company come to the conclusion that using Flash was a good business decision? It's been largely unsupported/disabled in mainstream browsers for _years_ now. They also knew for 3 years it was officially going to be deprecated in 2021. Sounds like despite that they continued to develop on the technology anyway?