Slashdot Mirror
Symbolic Violence Beats Lava Lamps All To Pieces
cdance writes "Traditional Lava Lamps, and of course email, are the tools of choice to notify your dev team that the build in your continuous integration system is broken. However, lava lamps, just like pink curtains and shag pile, don't really fit into the culture of many modern development teams. There is now a solution. Retaliation is a new Jenkins CI build monitor that automatically coordinates a foam missile counter-attack against the developer who breaks the build. It does this by playing a pre-programmed control sequence to a USB Foam Missile Launcher to target the offending code monkey."
They want their dot.com bubble era development culture back.
My job uses approximately the same tactics, although instead of a python script we have Dave the Project Manager, and instead of a foam missile launcher, Dave has a baseball bat. You see, unlike traditional product managers who have a background in, well, project management, Dave has a background in being a large and terrifying individual. So, our code builds every damn time.
Is this posting a sign that Slashdot has been hacked? Or perhaps it is sending apparently random information to sleeper cells? Letsee... if i try every third word... nope. hmh.
If you have a giant build, your design is not modular enough. Above some size, it's time to go to multiple intercommunicating programs.
If you have a giant build, your design is not modular enough.
That makes no sense. You can have a modular system and still make changes the require giant builds. For example, if your module is something in the base of your system it will usually require you to recompile most of the rest of the system. Being modular will not stop that because you need to make sure that what you did in that one module does not break the pieces that use it. Secondly, what you seem to be complaining about is rather that people might not be doing incremental builds using make or a make-like tool. So, yes, if you are always rebuilding the entire system for no purpose that is stupid.
We'd all have to wear plastic safety specs too...
Because I find things like this to be juvenile.
I am Slashdot. Are you Slashdot as well?
Did I just get laid?
Balmer set up a similar system at MS when I worked there. Only every time you broke the build, you had to take a drink. I'm posting anonymously just in case this was in the NDA...
Arnie says 'Girlie men'
..most people will break the build to play with the toy. ..some people would adjust scm credentials and make it look like someone else did it and got hit:)
Since everybody in the group already has a networked computer, a general-purpose system capable of inflicting considerable suffering, why not take advantage of that?
A few days of being stuck using the "Penal Image"(WinME, Incredimail, Bonzibuddy, 800x600), they'll be begging for a chance to redeem themselves.
That launcher just looks like another small way to degrade people.
If I worked in an office that did that, I would ensure the launcher kept on having mysterious accidents that rendered it inoperable. Like somehow falling 10 stories out of an open window.
So we've got two different ways of handling errors here. Say I made a serious mistake like breaking the build that 1000 people have to work on. Company A looks into how the mistake happened and exactly what needs to be done to avoid the mistake happening again, be that changing the procedure I used (e.g. running tests), training of me and coworkers to make sure we know to follow the procedure or automating the failed step so that we can't do it wrong (e.g. have the build server run tests before checking something in). Perhaps something can be done to mitigate the seriousness if such a mistake happens in the future, such as an automatic roll-back on the server. Company B's solution, on the other hand, is to humiliate me so spectacularly that I'll try my best not to cause a problem again.
What'll really happen is that I'll try my best to ditch company B in favor of a professional setup like company A. So company B ends up with the people who can't get to a better place. Don't manage errors by humiliating whomever you think is responsible, have the whole company learn from the error instead. If one guy could make a mistake, we could ALL make that mistake on a bad day. Blaming one guy doesn't solve that, learning and preventing the mistake from happening again does.
Is it just me or did the article actually mean something? Lava lamps, dev team, missile counter-attack, USB Foam Missile, code monkey... what the fuck am I reading?
And you still need (more than ever) regular builds and test executions while you refactor it into something more modular.
Hey, you can't do that! You can't go and crush his nice theoretical arguments with reality! All of his professors said that modularity would solve every problem, and it would take no work at all to achieve. How can they all be wrong? Among all of them, they have almost 2 years of real programming experience!
Comment removed based on user account deletion
Does this mean maliciously change production code?
Does it mean I commit a change that fails unit tests and that someone merges to the master branch?
Does it mean I push changes that prevent compilation repository?
Seriously, if build breaking commits are bad enough that you need to consider ways to stop them, and are small fry enough for this to sound cool....change your shit up so that build breaking commits are not blockers and never going to make it to production.
The lava lamp thing's pretty cool though.
"If I break the build I get a shit storm from my co-workers and getting to be known by managers as the reason why we slipped a milestone date that was arbitrarily imagined by someone that hasn't coded in 25+ years."
Then you're doing SCRUM and sprints wrong, code monkey.
This solution clearly was impossible in the "good old days." First of all, programmers once had offices with four walls and a real door. Back then, the favorite correctional action was a skunk in the desk's file drawer (yes, they had real desks, too!). Even during the era of cubicles, it would have been impractical to fire over the partitions blindly. Lastly, robotic armaments have come along way toward making corrective actions more selectively punitive.
However, this seems like a Disney version of management. Instead of foam missiles, wiring their chairs with remote controlled tasers would be far more effective. It might even become the basis for a new form of Agile programming. You will laugh at the suggestion until you read that it has been standard practice in China and India.
Unless you work for a place like SparkFun or ThinkGeek this sort of thing just isn't acceptable in today's corporate culture and frankly I'm not exactly weeping about it, it got annoying quickly and untalented people soon became untalented and unproductive. I'm not here to play with toys, I'm here to do a job that I get paid to do so STFU and stop shooting foam crap at me because I'm armed with administrator privileges and an open shell and I'm not afraid to fuck your day up by forcing you onto a whitelist in squid.
I suggest you get into consulting.
More probably it's his PHBs that are doing S.C.R.U.M. and sprints wrong and he therefore has no say in it. It's really sad to see all good ideas eventually get perverted by clueless MBAs and PMPs
And to think I spent my mod-points on trolls...
Mit der Dummheit kämpfen Götter selbst vergebens
At least that's what my hippy educators in the 70s liked to tell me. Though to render everything they told me false and irrelevant, I just need to find one example where it did. Hmm... Ah! World War 2! Suck on that, hippy educators! Perhaps you just didn't use enough violence in your solution!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You can structure your modules and your tests such that you can test them independently, using unit tests and functional tests while mocking other services. This keeps each individual build, likely to be kicked off by a change in the revision control system, to a minimum. Integration tests using all the components together can be kicked off at larger intervals (twice daily, for example). These should always pass if all the individual module tests passed. If not, then your tests are incomplete.
I'd like to print that out and put it up on my divider wall but I've already hit my limit of 3 personal non-work-related items.
I use the software that these guys churn out. It always works, does exactly what it says on the box, and has new features and updates added on a regular basis. The same can't be said for a lot of other "business" software that I've used, and is probably churned out by coders in environments diametrically opposed to the one portrayed in the video.
Whatever happened to society? Can't people have a bit of fun whilst working anymore?
Then he's doing scrum like most of the companies out there.
I've had managers scream at me because I wasn't burning down exactly 8 hours per day.
I've had managers pick arbitrary dates six months in the future as the Absolute Must Ship date, and complain when one month into that, we laid out the reasons why we didn't think we'd have all the desired features by then, demanding that we fix things so our burndown chart showed us completing on time, because obviously the problem was in the burn-down chart, not in the schedule or staffing level.
I've had managers complain when we re-scoped things after finding a problem, because it meant that the beautiful chart they'd made at the beginning of the sprint wasn't accurate anymore.
I've had managers complain that we didn't have tasks laid out in detail three months in advance.
SCRUM is great if everyone including management understands what it's about and how to do it. It's a nightmare if the guy in charge doesn't get it.
And what happens if you make a change to the build system?
We built the same thing last year, and the guys at Atlassian wrote up a blog post on us.
http://blogs.atlassian.com/devtools/2010/12/missiles-failed-builds-bamboo-punisher.html
If you have a giant build, your design is not modular enough. Above some size, it's time to go to multiple intercommunicating programs.
"When your national debt is huge, stop spending."
See, I think you're missing the real problem.
And all I read is "Whine whine whine, no one else should have any fun 'cause my life sucks"
Of course, as the system complexity increases, unintended consequences become more frequent. However, if changes in underlying modules cause categoric rebuilds, it really isn't a true component system. A component's ABI should be extremely stable under normal circumstances. Almost impossible to accomplish with C++ unless you sacrifice most of the object-oriented goodies, but easily achievable with almost any other language given proper developer discipline.
Grow a back bone! The rubbish only happens if you put up with it.
Looks like someone needs a foam missile launcher...
Carol vs. Ghost
Damn right, I was in a bubble company in 1999, we used to play Half Life deathmatch mid afternoon, go to the pub for lunch and decide not to bother going back to work. Oh happy days. I still get paid to press buttons on computers, there are no deathmatches and we try not to get TOO drunk at the pub but FFS it's just a job, it shouldn't define your existence
If you don't risk failure you don't risk success.
Those modules communicate with each other. If you screw up the way they communicate, integration tests fail. That's a broken build.
So wait...we're supposed to respect your choices and their results, and therefore respect and wish to emulate you, thus making your condescension about "toys" and "scripting abilities" have bite?
Does it occur to you that there is another possibility...that you screwed up, made a lot of poor decisions, and now justify them to yourself in terms of "growing up"? That it was your party that ended, not the party?
"We live as though the world were as it should be, to show it what it can be." - Joss Whedon via Angel
I'm being a bit over-cautious by posting anonymously.
Very profitable and ubiquitous code was written in this kind of atmosphere.
I worked for a 1000LB Gorilla business-oriented computing company in the 90s. I missed the boat, but a few years before I joined, the culture was very much - turn up mid morning, pub for lunch, stay in the pub til 6pm, back to the office, churn out code into the wee small hours, stagger home, repeat.
Serious mainframe code for serious business use was produced by that working model. It's likely some of that code still runs every time your supermarket re-orders Coke, or your payroll gets processed.
If you have a giant build, your design is not modular enough. Above some size, it's time to go to multiple intercommunicating programs.
I bet most giant builds aren't giant because there's actually so much building work that needs to be done; they're giant because the build system is *broken*. Can't do a proper incremental build, can't be parallelized, and so on. I once reduced a 15--20 minute build time to 0--15 seconds by fixing up the Makefile to do the right thing.
...I was clearly trolling in the post above.
They give mod points to anyone these days.
Mit der Dummheit kämpfen Götter selbst vergebens
It's not hard to reverse engineer a USB gadget with something like USBSnoop. From there, it's dead simple writing something in python to control it for you
Don't fucking call random people code monkeys. Mind your fucking manners, sir.
Some of my best code has been in the small hours after drinking, must be the Balmer Peak in action. I remember in the late 90s going to a beach party once, then afterwards bashing out a bunch of cookie handling code. I bet there are tons of websites still using that today :D
If you don't risk failure you don't risk success.