Symbolic Violence Beats Lava Lamps All To Pieces 128
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."
The 90's called (Score:5, Insightful)
They want their dot.com bubble era development culture back.
We have something similar (Score:5, Insightful)
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.
If you have a giant build, it's not modular enough (Score:3, Insightful)
If you have a giant build, your design is not modular enough. Above some size, it's time to go to multiple intercommunicating programs.
Re:If you have a giant build, it's not modular eno (Score:5, Insightful)
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.
I must be missing something (Score:3, Insightful)
Re:The 90's called (Score:4, Insightful)
They want their dot.com bubble era development culture back.
No, that was me calling. I wanted to go back to the 90s era development culture, as we seemed to get a lot more done back then.
Demeaning != Fun (Score:3, Insightful)
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.
Sigh (Score:2, Insightful)
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.
Comment removed (Score:5, Insightful)
Re:Demeaning != Fun (Score:1, Insightful)
Re:The 90's called (Score:4, Insightful)
Let me guess, you were born sometime after 1990, weren't you?
In the 1990s and the very early 2000s, this kind of behavior never happened at places making real profit. Why? Because developers at a place like that are too fucking busy making money. They are also talented enough to not fuck up constantly, and don't need goddamn build failure lights or co-workers hitting them in the genitals with foam sports equipment.
We only ever saw this nonsense at places made up of fools. You know, the sorts of places where they hired people with useless Sociology degrees to be programmers because they once turned on a Commodore 64 in their youth. When you put enough of these idiots together, especially doing work they have absolutely no clue how to do, and you end up with people throwing beach balls around the office rather than getting work done and making money. Oddly enough, these places end up going under! But the work environment was so much fun, the former employees would say. For the six months it lasted before the funding ran out, it was a great time!
The same thing is happening today. The Web 2.0 bubble is about to burst. We've got many Ruby on Rails "developers" and NoSQL "DBAs" all over the place working on unprofitable applications. They often waste time playing cubicle games instead of working. When the bubble bursts, they'll be out on their asses. Nobody will touch them, thanks to the terrible reputation that Rails and NoSQL are getting these days.