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!"
Can we fucking kill this meme right now?
[John]
Shit better not happen!
Brogramming is prototyping.
In the ideal project, you gather the spec in advance, carefully design, and then implement.
In the real world, almost everything is a prototype because the demands are not known. Your product may succeed for entirely different reasons than you expected. At that point, you're going to be re-coding. Once you present a prototype, people will have changes that are more than cosmetic. You're going to "hack" -- literally kludge around the expected design -- and force it to work.
At that point, you have a prototype. The correct response then is to go back and refactor everything to make rev2.0 a solid and powerful piece of software.
This doesn't apply in every case. If you've got a clear task that's more technical than business/social, you can draw it all up on paper and build it the way L. Lamport suggests.
But for the rest of us, 'brogramming' is just another way of saying "getting to rev1.0"
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.
I read that as "Why we should build software like we build Horses"
But then I am drunk at work today.
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.
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.
-73, de n1ywb
www.n1ywb.com
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.
Welcome to the Panopticon. Used to be a prison, now it's your home.
obligatory xkcd
This is my signature. There are many like it, but this one is mine.
Like dude, that is so totally rad. We should surf the brogramming waves some time. Grab some Java and feel that Ruby sun! We can do that C-walk over to the Perl ravine. Just Go! Remember when we did that Objective-C and got a total Brainfuck! Ah man, and that girl had triple D! But for shame, she had a Lisp. She totally wanted to see my Python. So righteous! I can't wait to Bash this weekend.
The G
Take a look at his biography. His experience starts mid-90s in large corporations. Maybe he thinks computing started then?
Ok, I give up, why you?
There was once a brogrammer from Slo
who coded with a bro named mo
together they flowed, to and fro
until they were both let go
Join the Slashcott! Feb 10 thru Feb 17!
Software and houses are not similer.
Of course they are.
For one thing, when people ask an architect to design a new home for their family, it's perfectly normal to call him back six months later in the middle of first fit and say that actually what they need is a skyscraper. With a secret underground lair. And access to open water, so unfortunately the urban site where half of it currently sits is no good and the whole thing will need to be relocated to the nearest coast. And the building regs have suddenly changed, so now instead of concrete and rebars, the whole thing has to be made of environmentally friendly engineered wood materials.
Moreover, just like houses, we have thousands of years of experience building software now. We've become pretty good at telling in advance which techniques will be needed, what order the different components will need to be built in, and especially estimating how long it's going to take and what it will cost.
Actually, maybe it is a slightly unfair comparison, because the amateurs who build physical structures, like that mile-long railway tunnel that was drilled from both ends and wound up out of position by absurd amounts like 4mm when they met in the middle, can't really keep up with software development professionals who can build precisely specified interfaces and get everything to fit together exactly on the first attempt.
That's mostly because the tools and processes for doing all of this in the software world are well understood throughout the industry, which in turn is because everyone practising software development has gone through rigorous training taught by people who are themselves experts with years of practical experience to draw upon. Engineers and architects try to do the same thing, but they just haven't quite nailed it yet. I guess software guys have an advantage here because those tools and processes are universal and uncontroversial, so everyone in software does things the same way and software project managers don't really need to co-ordinate their team to quite the same extent that, say, a lead contractor would when building a house.
But apart from that slight advantage because software development is so much better understood, I think it's perfectly reasonable to compare building a house to building software and expect things to work the same way. There's really no qualitative difference at all, and basically the same processes work just as well for both tasks.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.