Live data from Hacker News

Shitlist Driven Development (2016)

sirupsen.com

91–100 of 148 posts

Re: Shitlist Driven Development (2016)

#91
post #82

I don't remember the exact project or where I read it but one project added delay (using sleep function) to depreatected methods in order to discourage people using them. After every release, they increased the sleep time so that at one point it became impossible to use it without noticing it. Although I don't know if it is possible to do this for new code trying to use deprecated function and have old code use non-d…

That is hilarious! Also, a fair percentage evil. Nice trick.

100% evil and pretentious. Not every dev team has the free time to go rewriting everything to the whimsy of library devs that can't help themselves from incessantly shuffling everything around every week. This is how you encourage people to never update and keep security vulnerabilities in the wild.

Re: Shitlist Driven Development (2016)

#92
This is a good example of "Organization as Code", where you are trying to influence a non-trivial change (often "cultural") by code.

Frequently it's better to change behaviour this way than say, holding meetings and presentations.

A typical example is "we want our developer to write more tests" but there are few existing examples of test code to look at and when you write a test it takes forever to run, so you fix this by fixing the underlaying issues (which is bad or non-existing code), rather than making developers attend TDD presentations and just talking about a "test culture" for example.

Re: Shitlist Driven Development (2016)

#93

Earlier quoted context omitted.

> Why not use profanity in code? We're all adults. You just answered your own question there.

I think you're saying adults do not use profanity, but that doesn't really make sense.

Adults use words appropriately, not spamming profanity to the point that it's meaningless.

Re: Shitlist Driven Development (2016)

#95
post #82

Earlier quoted context omitted.

That is hilarious! Also, a fair percentage evil. Nice trick.

100% evil and pretentious. Not every dev team has the free time to go rewriting everything to the whimsy of library devs that can't help themselves from incessantly shuffling everything around every week. This is how you encourage people to never update and keep security vulnerabilities in the wild.

Really? That’s basically the premise of every JavaScript web framework.

Re: Shitlist Driven Development (2016)

#96

We use Bazel’s visibility settings this way. More often for controlled beta rollouts than for deprecation, but same principle. You can make it a compile time error to import a package that isn’t for you.

Yes, this is exactly what we do inside Google - it works even better when (a) everyone uses Bazel for everything and (b) all the commonly-used languages have dependencies checked at compile-time.

Re: Shitlist Driven Development (2016)

#97
post #82

Earlier quoted context omitted.

That is hilarious! Also, a fair percentage evil. Nice trick.

100% evil and pretentious. Not every dev team has the free time to go rewriting everything to the whimsy of library devs that can't help themselves from incessantly shuffling everything around every week. This is how you encourage people to never update and keep security vulnerabilities in the wild.

We're talking about transitions where the library authors deliberately want to (and have good reasons) to migrate whole organization over. It's not they who are pretentious in your scenario ;)

Re: Shitlist Driven Development (2016)

#98
post #82

Earlier quoted context omitted.

That is hilarious! Also, a fair percentage evil. Nice trick.

100% evil and pretentious. Not every dev team has the free time to go rewriting everything to the whimsy of library devs that can't help themselves from incessantly shuffling everything around every week. This is how you encourage people to never update and keep security vulnerabilities in the wild.

It is especially evil since on many systems old methods are more performant, because they were meant to be used on old limited hardware (where cycles and memory really mattered). So by making those slower... you 're really digging a hole. There are of course cases where the opposite is true too, like all things in life.

Re: Shitlist Driven Development (2016)

#99

Earlier quoted context omitted.

100% evil and pretentious. Not every dev team has the free time to go rewriting everything to the whimsy of library devs that can't help themselves from incessantly shuffling everything around every week. This is how you encourage people to never update and keep security vulnerabilities in the wild.

It is especially evil since on many systems old methods are more performant, because they were meant to be used on old limited hardware (where cycles and memory really mattered). So by making those slower... you 're really digging a hole. There are of course cases where the opposite is true too, like all things in life.

[deleted]
Post reply on HN