Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shitlist Driven Development (2016)

sirupsen.com

Post reply on HN
Print view View original

111–120 of 148 posts

Re: Shitlist Driven Development (2016)

#111

Post by awinter-py »

I love his specific examples.

> Make sure that a certain datastore is only read from in a certain context ... Ensure fallbacks for all uses of a secondary data-store ... joins between tables that have no business being joined

I wish linters / typesystems were extensible enough to do this kind of domain-specific checking. There's a new generation of static analysis that's much more focused on architecture or business rules and is less about code-in-the-small concerns like class methods or operator compatibility.

Re: Shitlist Driven Development (2016)

#112

Post by deckard1 »

reader_1000 wrote: post #78

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…

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.

Re: Shitlist Driven Development (2016)

#113

Post by Terr_ »

grupthink wrote: post #88
nerdponx wrote: post #73

Earlier quoted context omitted.

Another, less extreme version: "Your most important collaborator is yourself six months ago, and they won't respond to your emails."

I just spat coffee all over my desk. This is hilarious yet depressing since it reminds me that perhaps the human mind is like the ship of Theseus.

Or perhaps created anew every morning.

https://existentialcomics.com/comic/1

Re: Shitlist Driven Development (2016)

#114

Post by [deleted] »

reader_1000 wrote: post #78

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…

[deleted]

Re: Shitlist Driven Development (2016)

#115

Post by Terr_ »

ben509 wrote: post #65
DonHopkins wrote: post #32

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.

Shiterator requires your system is able to consume fibers, though, or it'll dump all your kernels, which is not a pretty sight.

Isn't that backwards, though? More green threads increase the throughput of kernels, or at least decrease the processing latency.

Re: Shitlist Driven Development (2016)

#117

Post by ivraatiems »

gwbas1c wrote: post #37

I'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

Consider using the [Obsolete] attribute on methods or other entities you don't want people to keep using: https://docs.microsoft.com/en-us/dotnet/api/system.obsoletea...

This results in syntax highlighting in Visual Studio and warnings on compilation when somebody tries to use the method.

Re: Shitlist Driven Development (2016)

#118

Post by anonygler »

This is accomplished at Google using the build system. Your visibility declaration tells the build system what's allowed to depend on a piece of code.

When deprecating old code, you can shut that door with a whitelist and gradually force consumers to migrate.

I really like how code is managed at Google.

Re: Shitlist Driven Development (2016)

#119

Post by neilparikh »

deckard1 wrote: post #112
reader_1000 wrote: post #78

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…

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…

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.

Re: Shitlist Driven Development (2016)

#120

Post by mleonhard »

The article shows ways to prevent new dependencies on your deprecated library/service. This is half of the problem. The other half is efficiently removing the existing dependencies.

Your team could change the other teams' code to remove the dependencies. This is usually inefficient. You will waste time learning their code. They may drag out the code review process for weeks or months.

Some teams may refuse to accept your changes and use your service deprecation as political capital to demand more headcount. They may even lie to their managers and claim that the dependency deprecation is justification for a rewrite that they want to do.

There is a technical solution that can help with this social problem: AUTOMATICALLY EXPIRING DEPENDENCY APPROVALS. Configure your library to allow only existing systems to use it, and make them all break on a certain date. Then, instead of forcing the other team to move, they have to move or their build breaks. And if they want to delay turndown they must convince you to change your code. Without automatic expiration, they can delay turndown by simply ignoring you.

Some teams may wait for the dependency expiration, lie saying they didn't know about the turndown, and then demand that you delay the turndown and give them more time. You can work around this with a two-phased turndown. First create a new version of the library that allows only existing clients. Give the library a hideous name so code owners will want to remove it. Example: Deprecated_LiBrArY_YoUr_BuIlD_WiLL_BREaK_oN_20200601_LOL_Were_sERIUS_YOLO_exxtensuns_COme_frun_SVP_DaniELs_OnLY. Then set the existing library to expire in a week and email all users. They can easily switch to the new hideously-named library and in the process acknowledge that they know that their build will break at the specified date.

TLDR: Use expiring white lists so you won't get ignored. Rename your deprecated library to something hideous to motivate code owners to migrate away from it.

Post reply on HN