Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shitlist Driven Development (2016)

sirupsen.com

Post reply on HN
Print view View original

21–30 of 148 posts

Re: Shitlist Driven Development (2016)

#21

Post by donatj »

In a similar vein but on a smaller scale we have a number of tests for deprecated behaviors in our application code, and whitelist the existing code based on serializing the file name, method name, and the ordered list of parsed token types of the method.

That way minor alterations like changing a string or numeric value don't remove the method from the whitelist, but alterations to the logic of the given method require you to fix the issue while you're in there poking around already to pass CI.

Re: Shitlist Driven Development (2016)

#23

Post by ChrisMarshallNY »

That's a pretty good idea.

I think a key to doing large, multi-developer projects, is true modular design, with opaque APIs, and each module with its own project identity and lifecycle.

Not a particularly popular stance, as it means a lot more overhead in each project.

It does reduce the need for shitlists, though.

Re: Shitlist Driven Development (2016)

#24

Post by notabul »

JBorrow wrote: post #17
notabul wrote: post #16

Earlier quoted context omitted.

The idea of deprecation and death of code assumes that those using it can easily stop. That’s not always the case. When Flash dies Jan 12, 2021, you’ll see what I mean. There’s been so much misinformation about it, but there’s an OS datetime check in the Flash viewer code, browsers will disable the plugin even for some older versions not just new releases and have or will remove PPAPI and NPAPI support, and Windows a…

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.

Re: Shitlist Driven Development (2016)

#25

Post by dhosek »

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.

Re: Shitlist Driven Development (2016)

#26

Post by chapium »

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.

Re: Shitlist Driven Development (2016)

#29

Post by jcelerier »

gitgud wrote: post #28

On a somewhat related note: One of the biggest things I've noticed is that simpler pieces of software are less likely to be deprecated, whereas complex codebases quickly become legacy and abandoned...

... windows ? MacOS ? Literally every Adobe software ? Literally every large audio / video / 3d création software ? Every large game engine ?

I don't know, I notice pretty much the opposite in the field of software I know - smaller software come and go, but the large ones were there 20 years ago and will likely still be there in twenty years

Re: Shitlist Driven Development (2016)

#30

Post by V-2 »

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.

Flash is an example of an entire technology getting deprecated. The article only talks about the codebase level.
Post reply on HN