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.
Shitlist Driven Development (2016)
91–100 of 148 posts
Re: Shitlist Driven Development (2016)
#92Frequently 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)
#93Earlier 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.
Re: Shitlist Driven Development (2016)
#94Re: Shitlist Driven Development (2016)
#95Earlier 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.
Re: Shitlist Driven Development (2016)
#96We 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.
Re: Shitlist Driven Development (2016)
#97Earlier 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.
Re: Shitlist Driven Development (2016)
#98Earlier 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.
Re: Shitlist Driven Development (2016)
#99Earlier 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.
Re: Shitlist Driven Development (2016)
#100Very difficult to sell something named "Shitlist"