Live data from Hacker News

Shitlist Driven Development (2016)

sirupsen.com

11–20 of 148 posts

Re: Shitlist Driven Development (2016)

#12
post #3

This is an excellent way of using your (hopefully) already existing testing and CI infrastructure to change a social problem into a technical problem. As we all know, technical problems are by far the easier of the two. :) We used this technique to great effect at my previous day job, though under the more neutral name of "ratchet".

I like the term “ratchet” more because it communicates the underlying mechanism, which may be a useful tool in a broader set of applications.

Re: Shitlist Driven Development (2016)

#15
To an extent this seems to be related to more general automated detection of refactor targets/"code smells" (ironically) for which there exist tools already (e.g. linters indicated in the article) - I like this simple "list" approach though.

Re: Shitlist Driven Development (2016)

#16
post #4

Brilliant. It's a really good compliment to strangling certain parts of a large code base. As always the key is getting the information to the right people at the right time, and making it more difficult to make the wrong choices then the right choices.

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 already has an optional update to kill Flash support that will be part of regular updates in Summer 2021.

Even with three years of warning, it’s not ok.

It’s an extreme case of deprecation, being attempted by the best in the business, but it is inherently bad, and there’s hardly a good way of doing it.

Re: Shitlist Driven Development (2016)

#17
post #16
post #4

Brilliant. It's a really good compliment to strangling certain parts of a large code base. As always the key is getting the information to the right people at the right time, and making it more difficult to make the wrong choices then the right choices.

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.

Re: Shitlist Driven Development (2016)

#19
A similar kind of automated mechanism is required in distributed systems that allow for rolling upgrades. New functionality in upgraded nodes can't break not-yet-upgraded nodes and legacy behavior in not-yet-upgraded nodes has to be tolerated in upgraded nodes but only until the entire system is upgraded and then it is prohibited. Doing this wrong results in some really hard to fix production states.

Re: Shitlist Driven Development (2016)

#20
One can't always introduce a multitude of shitlists into different places in the code. This can impact performance and readability; and perhaps even more importantly - if the language used is not high-level with reflection capabilities, you will be counting on callers' participation in calling the semi-deprecated API with truthful "usage key" for looking up on the shitlist. Who's to say nobody reuses authroized keys for expediency?
Post reply on HN