
About those lava lamps - ColinWright
https://gist.github.com/marick/3ec112bc38b2af267e15
======
kaiuhl
Left alone to our own willpower, most of us would be less accomplished. We'd
live in dirtier houses, wash the dishes less, and treat ourselves less well.
It's the promise of others seeing our accomplishments, being around our mess,
or seeing us naked that keeps us doing right by ourselves. Doing chores is a
chore, but social pressure and acceptance is a powerful drug.

~~~
codingdave
I disagree. I clean my home because I like it that way. I work better in a
clean, organized environment. I exercise because it makes me feel better and
stronger, and is just a good idea for long-term health. I work on personal
projects because I want the results of those projects to exist. About the only
thing I do for other people is my actual job, which pays the bills for the
larger home and more involved lifestyle that comes along with a wife and
children. (Well, I guess the whole raising of children and participating in a
marriage is done for other people. And charity work. But hopefully you get the
larger point.)

~~~
Retric
Have you ever cleaned up because company was coming over? Then clearly
external motivation was useful.

Now, you may have internalized a lot of this motivation, but at that point
it's not a question of willpower just habit.

~~~
Nacraile
Believe it or not, some people clean because they like things clean, not
because they want to impress other people. I am one of those people. A dirty
environment makes me miserable, regardless of whether anybody else ever sees
it (and I have many multiple-month spans of a clean apartment seen by nobody
else to prove it.)

> Have you ever cleaned up because company was coming over?

Yes, but irrelevant. Note that I don't make an special effort, I just move my
regular chores forward a bit so my place is seen at the peak of the cycle,
rather than the trough.

~~~
Retric
_the peak of the cycle_

That's normal behavior. The point is by moving up the cleaning cycle you’re
reducing the time in a trough which increase the average level. Aka
100,95,90,100,95,90... has a lower average than 100,95, _100_ ,95,90,100...

PS: Anyway, this is _most people._ If you’re an introvert that does not have
guests it's a non-issue.

------
samstokes
This is a great story, but describing the lava lamp as a "completely
irrelevant stimulus" misses a key insight into _why_ this worked: it
introduced (or strengthened) social pressure to fix a tragedy of the commons.

"Everyone knew broken builds should be fixed quickly", but each individual
felt a benefit of being able to push code without waiting for compilation /
tests to run. Breaking the build had a cost, but that pain was being
_distributed_ across the team (other programmers finding the problem), and
_delayed_ (waiting for them to complain). So the feedback loop was too weak to
discourage breaking the build.

This is a classic tragedy of the commons, and far from being "unreasonable" as
the author suggests, it's a fairly rational inclination for each individual
actor. Other people will find my bugs and breakages for me, and probably do
some of the diagnostic work for me too - why _wouldn 't_ I pass off that work
to them?

Since a team is (hopefully) a society rather than a competition, one answer is
"because I don't want to be known as a careless individual who creates work
for others". That's why paying attention to the lava lamp isn't "unreasonable"
either - everyone can see it, so it makes that social pressure much more
visible. It also means the cost of a broken build is less likely to get spread
across the team - if someone hits a problem, instead of puzzling for half an
hour whether the build is broken or they did something stupid, they can just
glance up and see the red lava lamp, and immediately exert social pressure.

By making social pressure stronger and more immediate, the lava lamp pushes
the cost of breaking the build back onto the person who broke it. That
restores a missing feedback loop, which is often an effective way to change a
culture.

~~~
tetrep
In addition to all of the above, it creates one of the greatest impetuses
(impeti?) for programmers, an arbitrary and voluntary constraint. I don't
really have any evidence other than anecdotes, but every programmer I know
loves them in some form or another.

------
astazangasta
A better way to state this, rather than a reason/unreason lens:

"In every job that must be done / there is an element of fun. / You find that
fun and snap! The job's a game."

~~~
zeroxfe
Wait, so every task I undertake will become a piece of cake?

~~~
squeaky-clean
Games don't have to be easy for you to enjoy them (ever play Super Meat Boy,
or any old Nintendo game?).

Making a game out of fixing a bug before a lava-lamp bubbles up doesn't make
bug fixing easier. It just makes it into a more compelling option than taking
off for an early lunch after deploying.

~~~
squeaky-clean
Apparently there's a Mary Poppins' joke that went over my head.

------
wlesieutre
If you were to use a higher wattage bulb with a dimmer that lets you adjust
the melting time and then deliberately set that time to 15-20 minutes, would
people still try to beat it?

My guess is no. Once a person gets involved in picking the time, it stops
being a fun thing to challenge yourself against, and starts being your
annoying boss trying to micromanage failed builds.

~~~
unimpressive
Maybe you could fix it a bit by making the time semi-random. It's not nearly
as fun if it's a static clock and accurate down to the second.

~~~
TeMPOraL
It won't work either. You still have a person trying to play tricks on others,
people resent that. You've transitioned from a self-imposed PvE challenge to
an arbitrary one imposed by your boss. The game stops being a game and starts
being work with weird rules.

~~~
wlesieutre
Right, I think it works because it's arbitrary. It just happens to be in a
sometimes realistic timeframe for a fix, so you can make a game out of it. If
somebody else is setting/influencing the benchmarks, suddenly it stops being
fun. You'd complain about "This is terribly balanced. Timer should be at least
30 minutes. Nerf wattage next patch!"

For a naturally occurring timer, you just work within the constraints you're
given. That's what they are and there's nobody to blame or change it. (I mean,
you could easily put a lower wattage bulb in, but that won't occur to most
people)

Or maybe it's like the placebo effect where you know what's going on but
somebody could control the timer and it works anyway. Who knows?

------
marshray
At one company I worked, we had a rubber chicken. When you broke the build,
the rubber chicken lived on your desk until somebody else broke the build.

One developer got a little annoyed at this so he cut the chicken's head off,
then repaired it with hose clamps. It was sort of a Frankenchicken.

~~~
qb45
> One developer got a little annoyed at this so he cut the chicken's head off

That's exactly what happens when such games are overdone or (ab)used in
attempt to "compensate" for programmers being unsatisfied with whichever
aspects of the project.

~~~
Namrog84
I also feel like this potentially unfairly makes the deva who have to work on
more sensitive and critical sections look worse than they are. Perhaps it
breaks because its a far more critical and sensitive space? Or am I way off
base on this thought

~~~
marshray
The chicken was intended to be a silly friendly thing among our team, but not
everyone seemed to take it that way. Yes, I and my team earned the chicken
more than anyone mainly because 1) I seemed to check in the most code, and 2)
our projects all started with the letter 'a', so we got the blame on days that
multiple projects were broken.

Commonly we see many folks (particularly non-coding managers) treat a nightly
build as some sort of indicator of developer competence or code quality. I
have even heard anecdotes of devs being fired for breaking the build in a
sufficiently large organization (but not the one with the chicken). A
successful nightly build is one of those things that's trivially easy to
measure and on the surface looks like progress. But of course, the easiest way
to never break the build is to just never check any code changes in.

But I believe strongly that a nightly build should be treated as a tool like
any other: in any large software project there will be times when a dev makes
an honest mistake with the checkin process or simply _cannot_ succeed at
testing every interdependency by building on his own box beforehand. So give
the devs something to break, and this ought to be the function of the nightly
build. If the nightly is so critical to organizational progress that it simply
must not be broken, then you need to give the devs something else.

The system should be made to serve its users, and not the other way around.

------
javajosh
So what's a good way to build a build lava lamp in 2015? I'm thinking wall
adapter that has wifi and offers a simple webserver that switches on and off
on POST.

~~~
lotyrin
Lots of off-the shelf "smart plugs" these days, with varying degrees of open-
ness and convenience to their APIs.

Or for DIY, a cheap micro plus a opto-isolated relay board.

~~~
jakobegger
Something neat that I found out recently is the existence of solid-state-
relays. They are basically opto-couplers that can directly switch a load. You
can use them instead of normal relays, and drive them directly from a digital
io pin. Pretty sweet.

Or just get a particle photon with the relay shield. Extremely easy to set up,
and it comes with a REST API.

------
shmageggy
[https://en.wikipedia.org/wiki/Gamification](https://en.wikipedia.org/wiki/Gamification)

------
tantalic
We use a old traffic signal powered by a Raspberry Pi to similar effect. We
have found it quite useful in providing timely feedback and encouraging the
quick resolution of issues.

You can see pictures and source: [https://github.com/tantalic/build-
light](https://github.com/tantalic/build-light)

------
Shivetya
reminds me of the days when large computer hardware had warning lamps mounted
on top, whether it was a printer or tape drive, so that it was obvious to even
those unfamiliar with the systems that something was wrong. So it was almost a
sense of pride among the operations staff the lights were always out

~~~
pavel_lishin
_A problem light. Wow, Dad. What a super idea. No, you should always put one
of those on the ninth wonder of the world._

[https://www.youtube.com/watch?v=U65n3_lP0fo](https://www.youtube.com/watch?v=U65n3_lP0fo)

------
bananaboy
At a video game studio I worked at a while ago I hooked up some (real) traffic
lights to talk to our CruiseControl.NET server to report breakages. But
actually it was just for fun and didn't make any difference - the main thing
was that we managed to instil into the culture a desire to always have a
working build. Pretty much all the programmers were very proactive about
fixing breakages, even when it wasn't a programming problem. It was sometimes
possible for artists and level designers to break the build, and the
programmers would always be pretty quick to respond and help them figure out
the problem and to fix it or build in safeguards and tests to ensure they
couldn't check in broken stuff.

------
programminggeek
Programmers would be wise to understand how irrational people are and that
reason rules very little of our lives.

------
jhpriestley
Why do people treat a broken build as some kind of emergency, when you can
just revert the commit? It's a trivial fix that anyone can make in about a
minute.

~~~
marshray
Often this is done, manually. With a big enough team and code base, by the
time the brokenness is detected, more commits which depend on it will have
piled up.

