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

121–130 of 148 posts

Re: Shitlist Driven Development (2016)

#121

Post by acbabis »

fduran wrote: post #92

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 th…

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.

Re: Shitlist Driven Development (2016)

#122

Post by kbhn »

mattnewton wrote: post #104
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…

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?

Re: Shitlist Driven Development (2016)

#123

Post by jokab »

nerdponx wrote: post #73
boojing wrote: post #66

Earlier 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."

Just watched Tenet yesterday and this comment reminded me of the pincer technique

Re: Shitlist Driven Development (2016)

#124

Post by jokab »

agravier wrote: post #38
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.

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.

Also make sure you have enough RAM in your septic tank

Re: Shitlist Driven Development (2016)

#125

Post by mandada »

Terr_ wrote: post #113
grupthink wrote: post #88

Earlier quoted context omitted.

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

This is great! Thank you food sharing this!

Re: Shitlist Driven Development (2016)

#126

Post by mattnewton »

kbhn wrote: post #122
mattnewton wrote: post #104

Earlier quoted context omitted.

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 dele…

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.

Re: Shitlist Driven Development (2016)

#127

Post by [deleted] »

adewinter wrote: post #60
notabul wrote: post #24

Earlier 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?

[deleted]

Re: Shitlist Driven Development (2016)

#128

Post by Spooky23 »

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…

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)

#129

Post by nomel »

hchz wrote: post #107
izacus wrote: post #97

Earlier quoted context omitted.

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.

Re: Shitlist Driven Development (2016)

#130

Post by brigandish »

munchbunny wrote: post #102
grupthink wrote: post #88

Earlier quoted context omitted.

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.

I don't know about my whole brain, but my programming brain totally is. Now that I've been programming for a nontrivial number of years, it's happened enough that I no longer trust future me to understand anything clever that I do, so I spend much more time structuring code to require minimal context. Failing that, ample documentation, because future me will appreciate having an essay to read much more than current m…

This is depressingly familiar. I can't tell you the number of times I've got an error, searched, ended up on StackOverflow reading the answer, full of stuff I have no knowledge of. Get to the end, it was answered by me. More than twice.

Seriously.

I'm now more obsessed with documentation and the kind of code structuring you mention and have come to hate, viscerally, projects that lack documentation.

As a potential aside, I once took a course in ASP. We had a bit of time before the class started and the tutor had a chat with a couple of us. Some huge government projects were in the news for having failed and gone well over budget. He told me he'd worked for the company behind them and that they used to obfuscate the code just by stripping out all the comments so the government had to keep going back to them for work.

I think of that any time I hear "but the code is the documentation"…

Post reply on HN