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-delayed one, I think it was a nice trick.
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. Clever, but your coworkers still hate your guts.
There's a real reason to do something similar if you're developing for a memory constrained devices with a API someone else will use.
If you have objects your API functions return that API consumers will use, you want to make sure the objects don't suddenly grow in size, since that would eat into the memory that the consumers expect to use. So, you'd pad those objects with unused fields, and then if you need to add a new field, you can just use that padding area.
Something similar applies if you're sending objects over the wire, since you may not want to increase the size of the message later.
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”.
Back in 2000 we were mandated with a big push to eliminate all shared excel documents and turn them into real database driven products. There was this one department that had a huge excel database that was bringing the network to its knees. Around that time I had discovered that you could create a function in excel with the moniker of a null character (alt-255). We had used that for playing pranks on one another. Someone had the bright idea to put a function into the code that invoked a slowly increasing pause. That function was sprinkled all throughout their code and no one knew because you can’t see a null character.
A few months later that department was practically begging us to convert their excel document into a database project.
I read this, and thought to myself that a hacker would love to find that in code through analysis tools. They could then replace the delay with malicious code, and no one would be the wiser for quite some time.
Doing stuff like this seems creative and awesome at the time, but it breeds vulnerabilities something fierce. It also creates a nightmare for maintenance.
I would suggest a different approach of figuring out how much that Excel doc was costing the company every month, how much the company would save if the doc was converted to a real data service and Web front end, and then present the comparison at a meeting with management from that department - give them a chance to sign on before you take it to more senior management.
In this scenario I would argue that deleting a function abruptly without verifying impacts is significantly worse than gradually adding a delay. Usually when function deprecations occur impacted dev teams are notified on a shared distro of what's coming in future releases. Library maintainers at large companies typically don't have the bandwidth to investigate each project that uses their library to determine if deleting a function would detrimentally impact a production environment. What a deletion does do is block the downstream dev team in this hypothetical from deploying to prod as they investigate why their builds are suddenly failing (or crashing in prod!) and refactor an alternative solution. Do you really want to work in an environment where other devs feel empowered to break your builds and sprints ad hoc?
While an interesting tactic, I don't think it's a great idea as it may mean a poorer experience for the customer rather than just the development team.
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.
Here, a “shitlist” tracks existing uses of deprecated behavior within a large code base. It prevents new uses of deprecated behavior without disrupting legacy code. This is a temporary measure used to facilitate refactoring large code bases.
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.
I've experienced this first-hand. Joining an existing project and being put on test-writing duty very quickly turned me into our team's chief advocate of writing testable code.
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.
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"
This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...
It's better to use a Shiterator, which can yield pieces of shit on demand, lazily enumerate them just in time, and generate infinite streams of shit, instead of allocating all your shit up front, and having your shit together in one place.
That's elegant dungtional programming but it's not really relevant here as you are supposed to check if new crap matches any of the enumerated fecal matter; how would you do that against an infinite stream of diarrhea? I'd leave this to the type system if possible. And of course use a colon-delimited list for the occasion.
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.
Exactly. What's nice about this approach is it factors in the "behavioural economics" of developers. As the author puts it...
> At the end of the day, everyone needs to get work done, and if they see a code-path already being used from 10 places in the code-base despite these soft warnings–it doesn’t seem crazy to introduce another.
Even the best person with the best intentions will take a short cut under some circumstances, meaning to fix it later then getting distracted before that happens.
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.
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".
Readit News
This seems like a slight variant of SDD: dickhead-driven-development. Clever, but your coworkers still hate your guts.
If you have objects your API functions return that API consumers will use, you want to make sure the objects don't suddenly grow in size, since that would eat into the memory that the consumers expect to use. So, you'd pad those objects with unused fields, and then if you need to add a new field, you can just use that padding area.
Something similar applies if you're sending objects over the wire, since you may not want to increase the size of the message later.
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”.
A few months later that department was practically begging us to convert their excel document into a database project.
Doing stuff like this seems creative and awesome at the time, but it breeds vulnerabilities something fierce. It also creates a nightmare for maintenance.
I would suggest a different approach of figuring out how much that Excel doc was costing the company every month, how much the company would save if the doc was converted to a real data service and Web front end, and then present the comparison at a meeting with management from that department - give them a chance to sign on before you take it to more senior management.
Also, a fair percentage evil.
Nice trick.
Deleted Comment
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.
Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”
Deleted Comment
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.
> At the end of the day, everyone needs to get work done, and if they see a code-path already being used from 10 places in the code-base despite these soft warnings–it doesn’t seem crazy to introduce another.
Even the best person with the best intentions will take a short cut under some circumstances, meaning to fix it later then getting distracted before that happens.
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.
We used this technique to great effect at my previous day job, though under the more neutral name of "ratchet".