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…
Shitlist Driven Development (2016)
131–140 of 148 posts
Re: Shitlist Driven Development (2016)
#132I 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…
A few months later that department was practically begging us to convert their excel document into a database project.
Re: Shitlist Driven Development (2016)
#133Earlier quoted context omitted.
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?
They don’t care if you sympathize. The business or institution decides how it wants to prioritize replacement, and some projects miss deadlines.
If you think that every application running in an enterprise has stopped using Flash, you’re sorely mistaken.
Re: Shitlist Driven Development (2016)
#134Earlier 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)
#135Re: Shitlist Driven Development (2016)
#136Earlier quoted context omitted.
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?
Some businesses run on code more than ten years old. They don’t care if you sympathize. The business or institution decides how it wants to prioritize replacement, and some projects miss deadlines. If you think that every application running in an enterprise has stopped using Flash, you’re sorely mistaken.
Re: Shitlist Driven Development (2016)
#137Earlier quoted context omitted.
Slightly tangent, this reminds me of the story of the game developer that would allocate a few tens or hundreds of megs of RAM early on in the project and not touch it. He knew that as the project was nearing completion, they would get squeezed on available RAM. Then he could just go and delete a single line of code and, bam, tons of free RAM. This seems like a slight variant of SDD: dickhead-driven-development. Clev…
I knew someone who did this with humans at a bigcorp. He’d politick to transfer in new teams for the sole purpose of building a supply of cannon fodder. Staff up in good times, and purge fodder when layoff targets came to protect “his people”.
Re: Shitlist Driven Development (2016)
#138I'm more curious about how things like shitlists are implemented in different languages. Most of my experience is C#, where calling deprecated code triggers a warning. Considering that C# warnings will fail in CI, how would someone do a C# shitlist? Would it require some kind of #pragma, that would stick out like a sore thumb in a code review
We treat warnings as errors and use #pragmas in cases where obsolete members are used.
When marking members as obsolete we require it be commented with a Jira issue number to make sure removing it is not forgotten.
I also strongly encourage that an XML Document Comment is added with a to the replacement member which is navigable to by the IDE.
Finally, reviewers of the PRs just need to make sure these rules are applied, but it’s easy to spot #pragmas.
Re: Shitlist Driven Development (2016)
#139Earlier quoted context omitted.
Your comment made me think of the adage: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live"
Another, less extreme version: "Your most important collaborator is yourself six months ago, and they won't respond to your emails."
It's so helpful when I do it that I probably ought to do it more, and if there weren't so much overhead I'd probably do it everywhere.
Re: Shitlist Driven Development (2016)
#140Earlier quoted context omitted.
... 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
So you'd write a new application using win32? There is a lot of inertia driving maintenance on some of these large products but there is also a ton of deprecation taking place internally relative to them.