Show HN: When my builds fail I pay money to charity | Hacker News Reader

Show HN: When my builds fail I pay money to charity

medium.com

87 pointsjvardy77 comments

The interesting thing about this project is how the incentives align. The premise requires the view that donating to charity is a bad thing. Or conversely, writing build failing code is a good thing. Otherwise --if donating and buildable code are good -- there is no self reinforcing cycle. The system architecture is closed...a finite pie if you will. Successful builds and charitable donations have a reciprocal relationship. An increase in one comes at the expense of the other. A win-win system architecture would have a positive correlation between charitable donations and successful builds. The charities and the developer would both benefit or suffer together. If both successful builds and charitable donations are good, the system architecture encourages the Shirky Principle https://en.wikipedia.org/wiki/Clay_Shirky#Shirky_principle

Eh, there's always a limit though.

He chose donating because it’s a good thing. Reasonable amount of build failure is ok, just not excessively so.

It's a technological swear-jar. The pain is that it's taking money out of your pocket.

Neither of your requirements are true in the least. It’s a great idea because he’s penalizing himself for failed builds in a really fun way, with no waste because it’s going to a good purpose. It’s called “win-win” and it’s a good thing.

"penalizing himself"

Implies that OP is correct. In order to penalizing yourself you need to do something you consider a punishment. In this case donating to charity...

Involuntarily losing money is a punishment. Even if it goes to a good cause.

But surely 'losing money' to a bad cause would be an even better punishment. Is the punishment supposed to discourage breaking builds? Are the 'warm fuzzy feelings' (or the actual benefits of the relevant charity!) that causing a charitable donation to occur being properly accounted for in deciding whether this is a good idea?

OP and yourself are perhaps engaging in what could be termed as "semantic trolling"

Fortunately it isn't working because as others pointed out, "penalize himself" and "donate to charity" concepts aren't directly tied together. Where the donation actually goes is immaterial, so it's not possible to argue that "punish himself" implies "donate to charity" is punishment.

The only misuse of semantics I see is where an attempt to obscure a concretely causal relationship occurs:

mistake > punish himself > donate to charity to punish himself

Donating to charity as a method to achieve the punishment goal is precisely material in this case.

GP is asking if this method, which contains both a gain and loss, actually results in a punishment with an intended loss.

The punishment isn't donating to charity. The punishment is losing money.

Punishing himself is the losing money aspect. It doesn't matter where it goes technically for it to be a punishment. His goal is to not lose money.

But to make it worthwhile (aka the reward part of the punishment), the donations are directed to charity since they need to go somewhere. So that's a small reward built into the punishment.

If the money goes to "Starbucks" as shown in the image, I don't think he is being punished.

It's better than just throwing away money after a failed build. But a true win-win strategy is donating to charity unconditionally, and not wasting time punishing yourself for failed builds in an elaborate way ;).

You are advocating perfection while op is making the best out of the dealt cards. We need both approaches as a society, but one should not nag the other.

They were advocating not misaligning incentives, which is definitely not making the best of a situation.

You are not accounting for the fun that doing this entails. It's gamification of the build with a gaming partner that is actually fun to play with.

When I play a game with my buddies, I try to win, but even if I lose I still have a good time.

This is a very similar concept. Also, don't assume that this is the only money he gives. Games are fun.

In reality I was just nitpicking. Doing the win-win strategy I described does require more willpower, and I understand that one employs tricks like these to avoid using willpower.

Incidentally, I somewhat envy people who are capable to pull such strategy off. It requires some amount of suspension of disbelief, forgetting for a moment that you're the game master and playing the game by the book way past the point it's become uncomfortable. I don't have that. I tried many times, but my mind just refuses to participate in self-trickery.

> penalizing himself for failed builds in a really fun way

That doesn't make sense. Penalties aren't fun. Building software isn't a game (generally).

And there sure seems like there's a real possibility of wasteful behavior, e.g. someone 'spamming' the build system to effect a large overall donation.

Maybe view it as art that assigns meaning to an abstraction. A failing build is pretty obscure to most people, but giving to charity makes sense.

As a programmer I can sympathize with wanting to get my head out of the clouds once in a while. Sure, my customers use my software, but my internal build processes are invisible to them.

Donating money is something that has a short term sting but feels good in the long term. That short term sting gives the immediate feedback and the long term benefit means that the user will keep the system on. If my failed builds donated to Trump 2020 I wouldn’t keep the system on.

It would make more sense for build failures to donate to a cause that the user opposes. Perhaps you oppose the NRA, or the ACLU, or a certain political party. That ought to provide a strong disincentive.

As mentioned elsewhere, there needs to be some long term incentive to keep the system on at all that counters the short term financial disincentive.

If there's a separate incentive to keep the system on, then it doesn't function as a disincentive to cause build failures. If you're worried about keeping yourself honest (i.e. not turning the system off), then there could be an escrow service where you prepay and can't get that money back. After every build failure, the escrow contributes a small amount to the "bad" charity, then at the end of the year, the remaining funds get contributed to a "good" charity.

Freakonomics introduced the concept of the [anti-charity](http://freakonomics.com/2011/08/25/how-to-improve-iphones-ne...) that you don't want to donate to.

I would go one step further and pick an amount that I want to donate and then each fail action moves a unit of money from the "good" to "bad" bucket. ie start with $100 and each failed build puts $1 into the Big Endian / Kodos / Republican and each successful build the dollar goes into the Little Endian / Krang / Democrat charity bucket.

Relevant: http://stickk.com

In this system there is always somthing to stay positive about. Yay i wrote code that built, or yay i donated to a cause i believe in. I think everyone who is talking about incentives are over thinking it

I'm curious why you need to pay for a load balancer when you're running this as a service just for yourself. Sure it could fail, but it's not something critical and a LB just seems like unnecessary complexity/cost.

Everytime my build fails I effectively donated money to Amazon.

Ah, I was wondering who was subsidizing my free shipping. Thank you!

I am missing the point of the article. Why does build failing require any incentive or punishment?

If a build fails, nothing changes in the production environment. The developer can troubleshoot and fix the build. Pretty much like when local compilation fails due to a syntax error.

Why does such a routine thing as a build failure need to be rewarded or punished?

It’s a good habit to keep the commited code buildable. For team members, easier history changes, git bisect, etc.

Once upon a time, builds used to be very expensive and take forever. Entire development teams shared a single single-pipe build server, and builds could not even be built locally first.

We're (mostly) past those times now, but "breaking the build" is still in the mind of many devs as a negative behavior.

I'd imagine 'breaking the build' is, for almost everyone nowadays (and in most situations), a very minor issue. But it's still, all else equal, a net negative, however small.

Breaking a build once, for whatever reason, probably isn't a big deal. But breaking a build frequently certainly could be.

If you break our build, your pipeline fails and your code is not merged. Simple as that. The master branch doesn't break, because we don't merge broken code into it.

Not sure if I'm in to equating charity with failure or mistakes, but I suppose it's better than a complete lack of charity.

A few years ago, I had this idea of paying a small amount to charity every time I hit snooze on my alarm clock. I forked into an android alarm app, started working on it (but never completed it). My rationale then was that if I feel lazy and would prefer to sleep in further, I would penalize myself but in a way that would benefit someone else.

There was a study (referenced from a few books -- never read the study itself) where parents were required to pay if they didn't pick up their children from the kindergarten. Since setting this up reduced guilt (they were now paying for the care-takers' extra time) the average time of being late actually increased -- instead of decreasing as thought initially.

That's interesting. It's like introducing a late fee, or penalty fee, normalized the idea that being late is OK.

Kind of like introducing a defect lane on your factory line makes the workers feel like it's OK to have defects, and deters from quality.

That experiment could be fixed by penalizing every m minutes you're late with m*(1 + r) minutes of charity work, with r as the interest, at some point where the penalty has accumulated to some practical amount.

The economic premise of the kindergarten is already that parents would rather pay money than spend time with their kids.

Freakonomics mentioned this. It took place in Israel. It took a social faux pax and converted it to an economic transaction, thereby reducing/removing the stigma of being late.

http://freakonomics.com/2013/10/23/what-makes-people-do-what...

Which is great! The daycare discovered a lucrative business growth opportunity that help improve their customers' lives. Next step shout be to set a fair price for being late, so caregivers and parents can make mutually beneficial exchanges of time for money. Social mores are crude heuristics. Explicit prices can do better.

> Social mores are crude heuristics. Explicit prices can do better.

Social mores are actually huge efficiency boosters for humans. They remove the overhead associated with coordination, transactions and ensuring trust.

I understand that a lot of these don't scale to cities of millions and civilizations of billions, but some do, and we shouldn't be quick to replace them with the "newest and shiniest" (essentially replicating them at scale by burning energy).

I would not say great. I would say it’s useful and efficient in some circumstances, and unhelpful in others. There are some things that don’t scale, and social moores might act as a safety valve in those cases versus an economic transaction.

Some human interactions are only a few A/B tests away from turning into a Black Mirror episode.

I generally endorse this kind of reasoning but you should keep in mind that this doesn't work in part because a lot (probably most) don't generally endorse it too.

In the case of the daycare, the price wasn't intended to encourage parents being late at all. The actual price the daycare workers would probably want to charge is not a market clearing price, but a price so high the market doesn't clear. They probably felt trapped into haggling once they put any price on the practice at all.

> The daycare discovered a lucrative business growth opportunity that help improve their customers' lives.

"Staying open later and charging your customers for the service they receive during that time" isn't exactly a business secret. It also can be detrimental to the quality of life of the employees that are unsure of when exactly they'll be able to end their shifts.

Nth 9 minute snooze costing Nk^a (k>=1, a>1, probably 1.5-2) would fix that easily.

That's because the late fee wasn't set high enough.

Set it to something really high like $600 [0] and parents' behavior will change, problem solved :)

[0] https://news.ycombinator.com/item?id=15753206

It seems weird to have a constantly running a server and database for what could be implemented as a cron job which just calls an API for last week's/month's data.

But it guess if it is just for fun who cares :)

I would think that the consequences need to be pretty immediate to have a psychological effect. Seeing at the end of the month, "Wow, I broke the build 8x. I should be more careful." just doesn't carry the same sting as "Oops; there went today's coffee budget!"

Presumably you get an email or other notification when the build fails. So even though the deduction isn't immediate you still get the immediate feedback that you will be deducted.

Nice write-up. Strikes me as a little strange to donate to charity as negative reinforcement though.

Was thinking the same thing. This would increase my chances of failing builds.

It would be way more effective if you were donating straight to a competitor, or a political organization you do not support at all.

Why would it do that, since presumably you are already giving all the money to charity that you willingly give?

I’ll give money to charity in theory but in practice I don’t have time.

Maybe an alternative is a fixed amount going to charity where a broken build means a portion of that money essentially goes to the equivalent of /dev/null.

Or the department beer fund?

Doesn't that encourage the hoarding of best practices so one can drink at the expense of the less experienced?

Depends how much you donate.

Another approach is donating to a charity you despise. Some friends of mine use a mutual donation pact to get things done. Each sets a goal they need to accomplish by the end of the month, and hands the other a signed check for $50 for a charity or political campaign they hate. If they don't accomplish the goal, the other person drops the envelope in the mail.

It's very effective. :-X

This is the proper way to set up the disincentive, and you'll find it recommended in many places.

For instance, stickK sets up its commitment contracts with the option to donate to an "anti-charity":

https://www.stickk.com/faq/charities/Commitment+Contracts

It also allows you to donate to fan clubs of sports teams you despise :)

Wouldn't you always compile and test locally before uploading to CI? I understand that CI can provide some confidence about working in a standard hermetic environment, vs. potentially only on one developer's laptop, in a team environment. But why would a CI build ever fail for a personal project?

As an example, if you forget a file before pushing; all local tests will pass and abject failure remotely. You can do local checks for that sort of thing, but it's ~impossible or at least impractical to catch every case through automation even when developer does due diligence.

Impractical is the key.

So many people focus on how often the build is broken. That’s not the important part in CI. The important part is how often (% of day) the codebase is broken.

It’s not how often you break the build that kills the team. It’s how long it stays that way. Breaking it twice a week for five minutes each is better than breaking it once a month for an hour or two.

Why would a broken build affect the team? Are you pushing changes to master that don’t pass CI?

What don't you like about the other 5 answers you got to this question?

The point of CI is to identify integration issues, not a blame assignment system (the loaded way you ask the question is really not helpful). So we can work faster. Not so we can spend all day second guessing our push being afraid we will make the build red.

Any commit can have integration issues. With enough people committing, there is a build going on all day long. It won't always be ships passing in the night.

The answers given above are 1) forgetting to “git add” and 2) test suite takes too long. These are fine reasons to offload testing of your PR to a CI system, but why would you be merging changes that potentially break the build? Our highest-commit-volume repos have a queue system doing test-then-land. There’s still no way a change set that breaks the build gets in the way of one that doesn’t.

Wouldn't someone need to fix a broken build? Won't that take time, e.g. five minutes or two hours (or whatever)? And wouldn't it better to break it in a way that it can be fixed quickly?

I guess that it's possible that your code merging workflow allows everyone to work completely independently but some teams don't (and others probably can't). So a broken build is an impediment to other working being done.

Because it’s only your PR/diff/changeset that’s broken, and you don’t merge broken code?

Are you talking about a scenario where people are just freely pushing to master without a review/CI step? If you recognize the problem with this, why is “deter people from breaking a post-merge CI process” better than “make your CI process pre-merge”?

Not always. Some tests take a while to run and I might rather they run on the CI server than my own machine.

Generally if I'm moderately sure things pass I'll just push to CI. Even sometimes when I'm sure they'll fail I'll push to CI, then work on something else while it runs the build, then come back to check the output.

I personally almost never run a full test run on my local machine for any project where the test run will take longer than a couple of minutes. Generally speaking, my local computer can only reasonably have the code in one state at a time, and any time spent running the test suite on a potentially finished change is time that could have been spent working on something else.

I never merge something to master, or any branch that I expect other people to use without knowing that it's going to pass, but I don't see any harm in having failing builds on a personal branch (particularly if I later clean up my commits to ensure that no individual commit that gets to master ever fails).

I take a different approach. I keep a file for each project and make an entry each time I resolve an issue. This helps me understand how I created the bug.

Donating to charity, while an incentive, won't help me see the detailed lesson a year from now.

Solution looking for a problem.

Is it a solution though?

Pretty neat project. I guess the only question left is, how much did you donate to get it done?

I don't think a 9-paragraph Medium post is appropriate for "Show HN."

Does seem like a neat idea, but you'd probably be more likely to avoid failed builds if (a) the donation was immediate and irreversible; and (b) went to a charity or organization you vehemently disagreed with.

You should mail the mods if you want stuff like that looked into.

Regarding b....:

One of the founders of Saxo Bank motivated himself in a weight loss challenge, by pledging to donate ~30.000EUR to the danish communist party, if he did not make his goal.

(It worked, he made it).

Reply on news.ycombinator.com