Is 'Brogramming' Killing Requirements Engineering?

chicksdaddy writes "Veracode's blog has an interesting piece that looks at whether 'brogramming' — the testosterone- and booze-fueled coding culture depicted in movies like The Social Network — spells death for the 'engineering' part of 'software engineering.' From the post: 'The Social Network is a great movie. But, let's face it, the kind of "coding" you're doing when you're "wired in"... or drunk... isn't likely to be very careful or – need we say – secure. Whatever else it may have done, [brogramming's] focus on flashy, testosterone-fueled "competitive" coding divorces "writing software" – free form, creative, inspirational – from "software engineering," its older, more thoughtful and reliable cousin.' The article picks up on Leslie Lamport's recent piece in Wired: 'Why we should build software like we build houses' — also worth reading!"

Brogramming???

[Bigbutt]

Can we fucking kill this meme right now?

[John]

Never seen one

[Anonymous Coward]

Hollywood's doing as good of a job portraying programmers as they have every other aspect of technology. I've never seen this 'brogrammer' in the wild. I don't doubt that there may be small, isolated pockets of them but it's not exactly the cancer that is killing the industry.

Re:Brogramming???

[Anne_Nonymous]

Judging from some of the roofers I've known, drunk would be exactly the way to "build software as we build houses".

Depends on the product

[cs668]

If you was your time upfront and someone beats you to the market, who cares about the engineering!! If you capture the market for a new idea you can use a more formal process for v2 while your competitors missed out.

If you are building my pacemaker, then lets be formal from the start!!

Seems, dumb to make a one size fits all statement about hacking out some code vs. engineering.

Re:Brogramming???

[telekon]

I remember when we called this sort of thing "cowboy coding."

Now I feel so old, I'm imagining there were actual cowboys.

Re:Depends on the product

[schlesinm]

If you was your time upfront and someone beats you to the market, who cares about the engineering!! If you capture the market for a new idea you can use a more formal process for v2 while your competitors missed out.

Just like MySpace beat FaceBook to market and Netscape beat IE to market. Getting that first mover advantage really fueled their meteoric rise and long stay at the top.

Like houses??? WTF??

[n1ywb]

Anybody who thinks that software development should mirror home construction has obviously never built a house, lived in a brand new house and delt with the sorts of issues that arise, done any major renovations, or otherwise been exposed to the sort of shoddy cob jobs that permeate the industry. Here in Vermont you're always finding shit like balled up newspaper insulation in the walls, 100 year old knob and tube wiring, frozen pipes, banging pipes, lead pipes, lead paint, asbestos, vermiculite, front porches built from rotting wood, leaking roofs, freshly painted fronts but peeling backs, dry laid slate foundations, and other eye boggling crap, pretty much every house you look at. The architect might draw plans but belive me the construction crew will find a way to bungle them and will do whatever they damn well please to get the job done. I feel like somebody is stretching for an analogy. SOFTWARE IS NOT CONSTRUCTION! SOFTWARE IS NOT LIKE A HOUSE! FFS. Different types of projects require different levels of care. Blogs, social networks, and one off command line utilities do not kill people when they break.

Anyway as a software engineer I can tell you that I THINK in code. I draw diagrams sometimes, for the complex bits, as necessary. But if I code up a POC and it sucks, it's cheap to tear it down and start again. Not so much when you are building a house, get it right the first time or you will hate life. So it's a dumb analogy.

Requirements Engineering?

[hsmith]

Over my 10 years, I've worked on dozens of projects across quite a few clients.

"Requirements" are generally vague ideas, which change at the drop of a hat.

While I love the concept and practice of getting down requirements, personally, I have yet to see the practice really stuck to - even for multiyear, multimillion dollar projects. Great theory, but in practice...

Re:Why should we care?

[idontgno]

Exactly. Look at the market fail-crater that is Facebook.

Oh, wait, that didn't happen. Success and failure have exactly nothing to do with quality of the software product. "Good enough for the suckers" is the order of the day and the practitioners of this approach rake in billions of dollars a year.

So, yeah. I'm not sure what definition of "fail" you're using, but clearly it has nothing to do with revenues, market, or social impact.

Re:Like houses??? WTF??

[sandytaru]

Actually, your description of that new house is exactly like some code I've seen...

Re:Brogramming???

[Anonymous Coward]

I'm a cowboy coder and the big difference to me is that cowboy coders actually have the engineering background, but choose to take the fastest and potentially riskiest path to "production". I tend to do a lot of proof of concept code, and I usually have extremely short deadlines. You can always find a code-monkey to re-write mission critical portions of a software rodeo.

Brogramming isn't even really science IMHO. For example, most of the brogrammers I've met are typically under 30yo CSCI graduates that again, IMHO, have no business with a CSCI degree. They learned Java in college. Not computer science. Java. In my experience every brogrammer I've met is really just a Java copy/pasta chef. Most would be dumbfounded to explain how stacks and heaps work (God forbid they have to deal with endian-ness).

Finally, I just wanted to give "big ups" to CPAN - the cowboy coders archive of choice! :)

Handling management

[concealment]

Only to then get a big fat "NO" from management because "it already works fine".

This is where your department head or intermediate manager needs to raise the following issues:

* Security
* Expandability
* The ability to sell the code to others

For reasons like the above, I support extending liability to software. If it drops your data, it's an error in the code, and someone should pay. Watch management change their tune after that!

Also, to the parent comment:

In the real world, almost everything is a prototype because the demands were too unimportant to be written down in the rush to get something coded that was clickable

This is why many experienced coders eventually migrate into management. Their job becomes managing their employees' time so that management's demands are met, but also so that behind the scenes, the job can get done right.

Re:Brogramming???

[AwesomeMcgee]

You forget the other part of the equation, the corporotocracies where they have BA staffs that don't write requirements either, I guess MBA's are above all that work mumbo jumbo and just hang out while telling the devs to do something useful without giving us any bloody specs at all ever. It's not just startups that are running without requirements, it's the entire industry anymore. I don't know why, this used to be a given expectation of a dev's job that they would get requirements, but I guess somebody at some point decided we could just generate wealth for our masters without the slightest bit of input at all.

I guess it doesn't help that enough of us are smart enough to actually do just that, but still, it's bloody annoying!

Re:Prototyping

[AwesomeMcgee]

Thankyou. Honestly, proper agile takes a lot of discipline and skill, at the end of the day I think you can't do proper agile without at least 50% of the involved team having completed the "Learn programming in 10 years" book rather than the 21 days version. You have to have seen all the shit that doesn't work over and over again for so long before you can even begin to do any of the stuff that works, and catch people trying to do the same tired crap, getting stuck in design meetings that spin forever or the alternative of just jamming out a bunch of garbage without talking to anyone, wasting everyone's time asking every step of the way how you should do each little thing or structuring an entire module according to your own hair brained ideas and never looking at the rest of the systems structure to see how crap yours will integrate, spending a week fulfilling requirements nobody wrote but you thought were just important for your little piddly irrelevant piece of the puzzle or not being thorough enough in seeing the big picture so as to catch the shit that needs to be done but wasn't written down or even mentioned. So many ways to eff it all up, so many ways. So yeah, "Learn programming in 10 years" then help a team be agile properly and it'll work out far better than some wankers "learn daily standups in 2 days to solve all your problems" garbage or "waterfall because it's worked for everyone since the 70s!", or "agile, as in, just go get it all done without the requirements or any help whatsoever, better be good because I heard agile is good!".

I think honestly the biggest cause though hands down of all this type of just-get-it-done crap comes from MBA's being too good to actually do any work, more less any work *for* lowly developers, it's supposed to be the other way around! Therefore they never generate specs or requirements because they're supposed to be telling other people to do work, not doing work themselves, why else did they go to school to become SOOO smart?? Between those schmucks and the "programming is cool, I'm going to be the next zuckerburg!" weeners, the industry is rife with people utterly clueless. But I guess that just mirrors the real world...

Re:Brogramming???

[TheSpoom]

From a software engineer who has never lived in Silicon Valley, the whole idea is ridiculous to me. No team I've ever worked with would even consider working while drunk.

Maybe teams in California work differently, who knows. Personally, I know that any code I write while intoxicated beyond a certain point is complete shit. If you think yours does not, you're lying to yourself.

Not even going to start on how accurate the movie is to real software engineering (hint: it's not).

Re:Brogramming???

[Anonymous Coward]

There is, occasionally, a time and a place for having a drink or other psychoactive substance -- in moderation -- while working on a hard problem that's not yet generating production code. There are people who swear by this. This is not the same, however, as getting blaster on cheap beer and chugging pedialyte in the mornings to ward off the regular hangover. That second one is called alcoholism, not "brogramming".