Hacker News Reader

Comment by reader_1000 | Hacker News Reader

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.

View on HN

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.

That seems far worse than just deleting the function IMO. The dev teams that most need to refactor are the ones least likely to notice perf slipping.

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?

I assume they are welcome to use the old version, and this comes after an ignored deprecation warning. If not, then this deletion should come after a forced migration by whatever library team enforces a one version rule.

That broken build won't be pushed to production and affect users, but invisibly slowing down a production service and hoping someone notices via monitoring will probably pass tests, build fine and be pushed to production where it will affect end users. I absolutely want to work in an environment where the build fails rather than people play childish tricks to punish my users because I used a deprecated function, and hope I notice.

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.

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.

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 ;)

This is not a decision a library developer makes in a reasonable Engineering organization.

I think that really depends. If there are performance, compliance, or maintenance requirements for the new versions where this is being implemented, and devs are updating to, then it could be considered reasonable. You wouldn't be seeing these delays if you continue using old versions of the library. Freeze your dependencies if you don't want your dependencies to change.

That seems like a mutual discussion, and seems to me this kind of thing happens when it isn't.

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

This is a failure of the dev team not evaluating that libraries are stable enough for their organization. If you can't keep up with the iterations of the libraries you're using then you shouldn't be using those libraries in the first place.

Haha what a smart idea

Reply on news.ycombinator.com