Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Is 'Brogramming' Killing Requirements Engineering?

Soulskill posted about 2 years ago | from the made-up-words-you-already-hate dept.

Programming 432

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 Networkspells 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!"

Sorry! There are no comments related to the filter you selected.

Brogramming??? (5, Insightful)

Bigbutt (65939) | about 2 years ago | (#42761001)

Can we fucking kill this meme right now?


Re:Brogramming??? (5, Insightful)

Anne_Nonymous (313852) | about 2 years ago | (#42761039)

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

Re:Brogramming??? (2)

jeffmeden (135043) | about 2 years ago | (#42761065)

This is why roofers are responsible for the orderly arrangement of asphalt squares and not something delicate and precise like nailing two pieces of wood together...

Re:Brogramming??? (0)

Anonymous Coward | about 2 years ago | (#42761543)

Why, because carpenters are too pussy-ass to finish the jobs they start?

Re:Brogramming??? (5, Funny)

Tx (96709) | about 2 years ago | (#42761569)

I've seen many fights on slashdot in my time, but "carpenters vs. roofers" is a new one on me.

CSB (0)

Anonymous Coward | about 2 years ago | (#42761097)

Cool Story, Bro.

Re:Brogramming??? (5, Funny)

Anonymous Coward | about 2 years ago | (#42761287)

If houses are code, I think I found Perl [all-that-i...esting.com] .

BROdot (0)

Anonymous Coward | about 2 years ago | (#42761075)

this place needs an enima

Re:Brogramming??? (4, Insightful)

telekon (185072) | about 2 years ago | (#42761093)

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

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

Re:Brogramming??? (2, Insightful)

Anonymous Coward | about 2 years ago | (#42761349)

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! :)

Re:Brogramming??? (1)

N0Man74 (1620447) | about 2 years ago | (#42761477)

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

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

I think this refers to something completely different... I have a lot of respect for some cowboy coders. I can't imagine having the same respect for a "brogrammer".

Re:Brogramming??? (1)

JLavezzo (161308) | about 2 years ago | (#42761195)

Napoleon Bronapart and Broan of Arc both support your efforts.

Re:Brogramming??? (1)

ElectricTurtle (1171201) | about 2 years ago | (#42761253)

Broseidon, God the Brocean, raises a glass of amBrosia to this.

Re:Brogramming??? (5, Interesting)

gl4ss (559668) | about 2 years ago | (#42761263)

what killed specifications focused engineering is that management killed specifications - in startups there rarely is one, the product itself _is_ the specification, it's the engineering and product development.

so it's brototyping(building a prototype without knowing what it's for because that's part of the r&d as well). let's just put a b on everything, goes fine with babbling.

it would be so much easier if you were making something that was already known what it should do and how though - but most of that stuff seems to be already done so there's not that much of such projects(and those projects take friggin ages in their own bro phase.. case in point areva, they hadn't even finished designing control systems for a nuke reactor by the time the thing was supposed to be online originally, which is just fine since the building wasn't finished either).

Re:Brogramming??? (5, Insightful)

AwesomeMcgee (2437070) | about 2 years ago | (#42761585)

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:Brogramming??? (5, Funny)

Anonymous Coward | about 2 years ago | (#42761325)

I clicked that article and there is a image with the word scrogrammer. If that's the alternative, I suggest we just stop using words to describe things.

Re:Brogramming??? (1)

Anonymous Coward | about 2 years ago | (#42761507)

Bro...do you even program??

Re:Brogramming??? (0)

Anonymous Coward | about 2 years ago | (#42761559)

It will die only on the day that Pair Programming is replaced by Pear Programming.

Re:Brogramming??? (1)

cod3r_ (2031620) | about 2 years ago | (#42761573)

You are a brogrammer and you love it.

Re:Brogramming??? (1)

identity0 (77976) | about 2 years ago | (#42761577)

Bro, do you ecen code?

Prototyping (5, Interesting)

concealment (2447304) | about 2 years ago | (#42761023)

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"

Re:Prototyping (0)

Anonymous Coward | about 2 years ago | (#42761113)

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 were too unimportant to be written down in the rush to get something coded that was clickable

ftfy. and truth be told we all do prototyping, but we (the good ones at least) step back after the prototype is done and think long and hard about throwing all the code away in favor of doing it the right way.

Re:Prototyping (2)

MadKeithV (102058) | about 2 years ago | (#42761299)

ftfy. and truth be told we all do prototyping, but we (the good ones at least) step back after the prototype is done and think long and hard about throwing all the code away in favor of doing it the right way.

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

Handling management (3, Insightful)

concealment (2447304) | about 2 years ago | (#42761553)

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:Prototyping (2)

gbjbaanb (229885) | about 2 years ago | (#42761153)

except you forget ever0changing requirements do not change, so once you have your working prototype and you begin to "refactor everything" (a misnomer if I ever heard one) you are going back to step 1, just with more of a clue than you had when you started.

Agile techniques were invented to deal with this problem, but they are in no way the ill-disciplined bullshit way of coding the article is describing. Agile requires you to be very disciplined in fact (and I refer to "proper" agile, not the "Agile" nonsense that masquerades as agile when someone tries to sell you some agile training course or materials).

For most of us, "brogramming" is just a way of saying "kids trying to appear cool and think they're the greatest". The rest of us can do all that shit without the inefficiency and poor practice associated with this type of playground activity.

Re:Prototyping (2)

serviscope_minor (664417) | about 2 years ago | (#42761177)

Brogramming is prototyping.

Yes, because prorotyping is best done in a booze and testosterone fueled haze.

Re:Prototyping (2, Funny)

Anonymous Coward | about 2 years ago | (#42761461)

Some of my most productive coding sessions have been late at night after a night drinking with friends in a hot and crowded bar, grinding with girls, and maybe even getting some head in the bathroom :)

There's a certain urgency, determination, and focus that just isn't there at other times.

These days, I do a line of coke once in a while for a similar effect but it's not the same thing.

Re:Prototyping (2)

Skapare (16644) | about 2 years ago | (#42761219)

And that's OK for things where security doesn't matter like Facebook or Google. But not for banks, medical devices, airplane controls, military ...

Re:Prototyping (1)

Creepy (93888) | about 2 years ago | (#42761235)

case in point

TCP/IP was quickly created by some students and released into the world, and then improved on. OSI was developed over years of specifications before even attempting to be implemented, and then it was so difficult to implement it took years before a working version even existed (I believe it was 7 years before they had a working model in a lab after the spec was finalized, and that spec took forever as well). Networking engineers think OSI is vastly superior from a design standpoint, but TCP/IP does the job and easily controls the market.

Re:Prototyping (2)

jandrese (485) | about 2 years ago | (#42761517)

TCP/IP has one huge advantage: Simplicity. It's easy to underestimate the advantage of keeping something easy to understand and simple to implement/maintain.

Re:Prototyping (0)

Anonymous Coward | about 2 years ago | (#42761503)

Prototyping is prototyping. Brogramming is an abomination.

Never seen one (5, Insightful)

Anonymous Coward | about 2 years ago | (#42761037)

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.

The equestrian pattern (5, Funny)

fatgraham (307614) | about 2 years ago | (#42761041)

I read that as "Why we should build software like we build Horses"

But then I am drunk at work today.

Why should we care? (1)

jdoss (802219) | about 2 years ago | (#42761043)

Let a "brogramming"-managed team release product into the marketplace and see what happens. When it fails, we will yawn and continue doing what we've been doing.

Re:Why should we care? (4, Insightful)

idontgno (624372) | about 2 years ago | (#42761323)

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.

Depends on the product (5, Insightful)

cs668 (89484) | about 2 years ago | (#42761045)

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:Depends on the product (3, Insightful)

schlesinm (934723) | about 2 years ago | (#42761135)

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.

Re:Depends on the product (1)

gl4ss (559668) | about 2 years ago | (#42761293)

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.

pretty shitty examples considering that lack of specs killed neither MySpace or Netscape(we're still using specs netscape came up for lot of stuff aren't we?) and neither FB or IE were written exactly to any spec originally....

with a pacemaker you know what the thing is supposed to do and within what parameters. with coming up something like facebook they didn't.

Re:Depends on the product (0)

Anonymous Coward | about 2 years ago | (#42761539)

Netscape was rewritten from scratch.

Re:Depends on the product (1)

cs668 (89484) | about 2 years ago | (#42761319)

Being first doesn't always make your product. But, it's a nice problem to have to be first. I can promise that if you are trying to raise money you will be asked, "who else is doing this and how far along are they"

Oh look, a buzzword (2)

Sir or Madman (2818071) | about 2 years ago | (#42761049)

Let's hope all this bro-gramming doesn't result in a coding-gate!

That's why you see a lot of crap code (2)

boddhisatva (774894) | about 2 years ago | (#42761063)

I do computer science - discussing work over beer is fine, but designing software - that requires a clear head and some caffeine. I like the saying "Mathematicians are machines for turning caffeine into theorems."

Re:That's why you see a lot of crap code (1)

Skapare (16644) | about 2 years ago | (#42761257)

And you are sure it can't be alcohol?

Yay, Waterfall! (1)

agizis (676060) | about 2 years ago | (#42761067)

Summary: Author wants us all to start using Waterfall Methodology because he is totally unaware of how it worked out in the 80's and 90's.

Re:Yay, Waterfall! (2)

gbjbaanb (229885) | about 2 years ago | (#42761305)

pot, meet kettle :)

See the second picture [stackexchange.com] on the first answer. Notice how the waterfall system as described by the original inventor shows how it iterates backwards until the major steps are completed. Surprised that waterfall isn't quite as waterfall-y as popular fable suggests?

The problem with the 80s/90s waterfall led projects were external to the methodology used. The concept of up-front design can work, if you understand you need to be a little bit flexible. I'd say there are a lot of projects today that are being built using Agile methods that will be seen to be total failures in the future (ok, they're not truly agile, they're usually bastard versions of some PMs idea of a good time spent planning) but the simple fact that you can't blame the method for human fuckups should be clear to all.

Except 'brogramming' which is pure human fuckup right from the start.

Re:Yay, Waterfall! (0)

Anonymous Coward | about 2 years ago | (#42761439)

And off course Agile is magically going to solve all our problems.
My Agile guru told me so, its on his website. So it must be true.
In the past everybody was using waterfall, which was evil, and caused all of our problems.
Nothing every succeed in the past, right?
Just paint everything black & white: The old was methodology is bad, the new is perfect.

Lot's of best practices were invented waaay before the Agile movement came along.
(For example: Iterative development was invented at the end of the 70's)
But no: Lets forget everything from the past and make some of the same mistakes again!

Read up about the history of software development.
Once in a while a new methodology comes along, promises heaven and becomes the new hype.
In reality the world is more complicated.
The same is happening over and over again.

We should build software like we build software (2)

ZombieBraintrust (1685608) | about 2 years ago | (#42761077)

... not houses. Software and houses are not similer.

Re:We should build software like we build software (2)

telekon (185072) | about 2 years ago | (#42761249)

Definitely. But to be fair, we should make floating point operations like we make house-building operations, because the return values both have floors and ceilings.

Re:We should build software like we build software (1)

invid (163714) | about 2 years ago | (#42761425)

Software and houses are not similer.

While software and houses are not similar, you could use building a house as a simile for building software, so in that way they are "similer". (I think you just made up a new word.)

That said, I think the point they are making is that you should have a plan before building a house and you should also have a plan before building software, and not just jump right in.

Re:We should build software like we build software (5, Funny)

Anonymous Brave Guy (457657) | about 2 years ago | (#42761575)

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.

Brogramming was a joke (1)

Fujisawa Sensei (207127) | about 2 years ago | (#42761101)

Brogramming is a joke already; get over it.

The answer is no (0)

Anonymous Coward | about 2 years ago | (#42761115)

As with all headlines formulated as questions.

The Social Network was just a movie and not scary (0)

Anonymous Coward | about 2 years ago | (#42761119)

Brokeback Mountain UML is the movie that should have you question 'brogramming.' Not that theres anything wrong with that.

he doesn't know the history (1)

sribe (304414) | about 2 years ago | (#42761137)

"writing software" – free form, creative, inspirational – from "software engineering," its older, more thoughtful and reliable cousin.'

Bullshit. The free-form, creative, inspirational kind is decades older than "software engineering".

Re:he doesn't know the history (1)

foma84 (2079302) | about 2 years ago | (#42761407)

I don't know where that comes from, but it's total bullshit, plain wrong, and should never come from somebody writing an article about programming.

Re:he doesn't know the history (0)

Anonymous Coward | about 2 years ago | (#42761519)

The word 'Bullshit' however, is even older than free-form, creative, inspirational programming.
It's a way of dismissing something, without making an argument.

Happens a lot on projects too:
Programmer A: "Maybe, we should talk to the customer. After all, he is going to use the software and he pays for it."
Programmer B: "Bullshit! This is free-form, creative, inspirational programming!"

Not to be confused with Bullshit programming, though.

Re:he doesn't know the history (4, Interesting)

h2oliu (38090) | about 2 years ago | (#42761433)

Take a look at his biography [veracode.com] . His experience starts mid-90s in large corporations. Maybe he thinks computing started then?

Like houses??? WTF?? (4, Insightful)

n1ywb (555767) | about 2 years ago | (#42761185)

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.

Re:Like houses??? WTF?? (4, Insightful)

sandytaru (1158959) | about 2 years ago | (#42761335)

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

Re:Like houses??? WTF?? (1)

Anonymous Coward | about 2 years ago | (#42761351)

I agree. Software engineering is more like a car.

Re:Like houses??? WTF?? (1)

endus (698588) | about 2 years ago | (#42761515)

I agree about some of the smaller projects, but the problem is that as a security engineer I consistently see the exact type of coding you allude to with your house analogy in bread-and-butter production systems. At one place I worked the developers couldn't even tell us what port range their application used to communicate...and this was in probably the most sensitive environment where faults were unacceptable that you can imagine...on an 80K node network. They were literally unable to provide us with that information. That type of incompetence isn't going to fly for much longer, and yet I see it everywhere.

If it were just a problem with small internal utilities or meaningless social media stuff I would agree, but it's not.

Re:Like houses??? WTF?? (1)

drinkypoo (153816) | about 2 years ago | (#42761545)

I feel like somebody is stretching for an analogy. SOFTWARE IS NOT CONSTRUCTION! SOFTWARE IS NOT LIKE A HOUSE! FFS.

Notably, it costs you money to make changes in a house, and you can't just copy a house and then start working from there. Whereas it doesn't necessarily cost you anything to make "changes" to incorporate a library, if you designed for it in the first place. You can buy prefabricated sections but you can't simply copy and reuse them.

When people build software, even if they have the "blueprints" that tell them what the "foundation" will look like, often they're not starting there. Either they're starting with some simpler code they've written and writing an application to make use of it, or they're planning to draw in a lot of code from some other source... or both.

Emotions (0)

Anonymous Coward | about 2 years ago | (#42761187)

An observation I made of the way gamers play 1st person shooters is that they don't do what's rational but what emotionally comforts them in the moment. If you do what's analytically correct to do instead (eg hide and wait instead of running around like a wild thing) you can usually beat them.

There is no reason why the same principle doesn't hold for programming.

Or why we should not build software like houses (3, Funny)

Max_W (812974) | about 2 years ago | (#42761189)

We all know how much corruption goes on ( allegedly and sometimes) around construction and urban development.

Good software means much more. It requires honesty, integrity, empathy, even a talent.

Re:Or why we should not build software like houses (0)

Anonymous Coward | about 2 years ago | (#42761363)

Corruption is a good explanation for many software phenomena.

never seen one (1)

Anonymous Coward | about 2 years ago | (#42761191)

I've never seen one of these "brogrammers" in the wild. The few people I have met that come close to this attitude were definitely outliers and outcasts. To think that they are taking over the industry is laughable. When your argument is based on a Hollywood portrayal of a character, you're really reaching for substance - they're not known for being realistic in their portrayal of things. From war to love, they've managed to get it wrong; why would they be right this time?

Requirements Engineering? (3, Insightful)

hsmith (818216) | about 2 years ago | (#42761207)

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...

"brogramming" = nothing to do with testosterone (0)

Anonymous Coward | about 2 years ago | (#42761209)

It's about latent homosexual desire.

Testosterone is about tissue growth in your body.

"Brogramming" is about doing everything with your male partners except have sex.

Re:"brogramming" = nothing to do with testosterone (1)

Haxagon (2454432) | about 2 years ago | (#42761409)

Yeah, men enjoying things with men is now gay. Next, testosterone will be oppressive, and castration preferred. Give it a rest.

New Rule. (0, Flamebait)

American AC in Paris (230456) | about 2 years ago | (#42761211)

OK, new rule.

Every time Slashdot posts an asinine, hit-trolling, golly-gosh-gee-what-if article like this one, they need decrement all red hues by #01 and increment all blue hues by #01.

This rule will hold until Slashdot reaches a color more appropriate to the caliber of its reporting.

Slashdot: It's like FOX news, but for liberals. (0)

Anonymous Coward | about 2 years ago | (#42761493)

Slashdot: It's like FOX news, but for liberals.

Steve Jobs was Sober??? (0)

Anonymous Coward | about 2 years ago | (#42761217)

Do you think Apple was made by strait-laced, sober people? They are "only and all hippies" and not "nerds".

mythical creature (1)

stenvar (2789879) | about 2 years ago | (#42761221)

divorces "writing software" – free form, creative, inspirational – from "software engineering," its older, more thoughtful and reliable cousin

When is this mythical creature supposed to have lived?

Re:mythical creature (1)

Haxagon (2454432) | about 2 years ago | (#42761511)

Never. It's obvious this is just linkbait. If Software Engineering came before people actually having a good time and being able to intuit about their code (what they call "brogramming" doesn't really exist, except in code-focused parties and cheap Hollywood flicks), then the vacuum tube predates the abacus. This is absolute bullshit.

I also have a problem with people using this idea of "brogramming", blaming it on testosterone, and then denouncing both. It's just college kids who are doing this, and I've seen women at those code-oriented parties, too. In some, they outnumber the men. This is conflating being able to intuit your code and having fun with your code, while trying to push the idea that "if you're not a tightass, you're not a good author". Complete bullshit. Some of the most elegant KLOCs I've seen have been because someone's "gotten in the groove", not because they've precisely engineered their code. That's not to say that standards of programming and clean code don't have their place (they do!) but the idea that clean-cut engineering is unequivocally superior to intuitive coding is unfounded.

That's because coding and design are different (2)

sandytaru (1158959) | about 2 years ago | (#42761223)

A designer can come up with workable a software layout without writing a single line of code. A coder, on the other hand, who tries to write a program without that blue print is probably going to miss something vital.

The superstar programmers are the ones who are adept at both roles, but the run of the mill coder is not a super star. and the run of the mill designer hasn't gone much beyond do-while loops in an introductory Java class. Separate out the analysts from the programmers, treat them like the two roles and two separate skill sets that they are, and you'll produce better software all around.

Pure Fiction (1)

stevegee58 (1179505) | about 2 years ago | (#42761277)

So-called "brogramming" is simply a fictional creation made for movies by non-engineers and non-programmers.
The closest you'd come to seeing this in reality might be a group programming project at a university.

To paraphrase an outstanding (literary) author... (1)

Anonymous Coward | about 2 years ago | (#42761317)

Code drunk, edit sober.

Somebody's gotta do it (4, Informative)

king neckbeard (1801738) | about 2 years ago | (#42761329)

obligatory xkcd [xkcd.com]

Fluff article... (3)

MrNemesis (587188) | about 2 years ago | (#42761331)

....that seems to exist solely to either attempt to coin a phrase, or just blindly continue the meme of prepending "bro" to everything.

Coding has, sadly, always been "testosterone fuelled" simply by having so many more men in the profession than women for the majority of its history, despite the fact that the vast majority of nerds, geeks and just plain computery types are far and away from what I'd see as a "bro" (although as a recalcitrant Brit I might not fully grok the term, is a "bro")
I've not yet met any programmer (or indeed any slightly competent professional) that hasn't overindulged in various psychoactive substances at some point in time

The article seems to base it's findings on having watched The Social Network, and seems to think that because a college undergraduate and his mates became hojillionaires after a few beers (yup, it was totally that simple) that this is why software quality is going down the pan. Stupid privacy issues aside, I was under the impression that facebook had a fairly good track record on actual server security because it already had put a large emphasis on engineering standards; even if they don't, they wouldn't be the first company that started out as some frenzied and possibly coding session and later put on a professional hat and cleaned up its act. I wonder if Larry and Sergey had a beer fridge at Stanford?

The real reason "quality software" is apparently seen to be disappearing is because a) software engineering as a "methodical, engineering-heavy discipline" is both difficult and expensive, not to mention seen as boring by many, so many companies and individuals will skimp and b) because barriers to entry are so low and there's so much *more* software out there now (including just as much good, if not great stuff), it could conceivably give the impression that "good software" is drowning in a sea of mediocrity.

My 2p.

Tubular (5, Funny)

RedHackTea (2779623) | about 2 years ago | (#42761339)

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.

Re:Tubular (0)

Anonymous Coward | about 2 years ago | (#42761541)

You know what would be fun? Of course you don't I haven't told you yet. The answer is to know how long is spent on typing up a comment like the above. See if it took you only a few minutes then it's funny but if it took you since this article appeared it's not quite as funny. How can we judge if we don't know? This took me over 5 minutes so it's likely not that funny.

That's what (1)

conscarcdr (1429747) | about 2 years ago | (#42761345)

Rails Girls is for.

Bad code... survives (1)

Dystopian Rebel (714995) | about 2 years ago | (#42761361)

There are many forces apart from incompetence acting upon any non-trivial software project. There are compromises to be made, and risks to be evaluated.

In short, there are factors that have nothing to do with the code that affect the quality of code.

The larger the organisation, the greater the tendency towards failure to understand, failure to communicate, and failure to complete. It isn't simply a question of architects, coders, testers, and documenters doing their very best.

There are some coding projects that are as essential as housing, in the sense that defects might cause death. But the majority of coding done in the world is slapped together and discarded within a five-year cycle.

What the heck, if it's for revenue recognition, release the prototype and hire e-workers to post favourable comments on some Web sites!

To paraphrase the Shat, "Bad code... survives."

Stupid Article (1)

cfulton (543949) | about 2 years ago | (#42761367)

Stupid Idea. I would like to see them brogram weather prediction or the control system of a jetliner. WFT. I guess we must endure stupid tech writers.

Re:Stupid Article (0)

Anonymous Coward | about 2 years ago | (#42761567)

So that's what happened to the Boeing Dreamliner..

Agile enough to fail (1)

Anonymous Coward | about 2 years ago | (#42761377)

Take away the booze and you get agile the current management darling that does away with pesky things like requirements and design. Seriously though agile, extreme programming, or whatever team coding buzz word you apply to it is nothing but the naked obsession with speed of delivery. It doesn't matter if it solves the right problem, or even if it works. Just delivery it now Now NOW.. NOWNOWNOW!!!!!!!!!!

Agile is the ultimate realization of the management dreams that "If I don't understand it it must be simple", "What have you done for me today", and the ever popular "Yes damnit with adequate beatings Rome most assuredly could have been built in a day".

The most dangerous part of this deranged thinking is that to a certain extent it is true. There is no good reason why a static web page needs a month of requirements, layout, design, inspections, and of course a 5 week QA cycle. But like just about everything else in the real world this does not scale. The further you get from "Bob's Blog" and into "Global Enterprise B2B solutions" the bigger fool you make of yourself by demanding "A daily shippable product" and "Major release every 2 weeks"

House-building is a terrible analogy (1)

TheMathemagician (2515102) | about 2 years ago | (#42761381)

The analogy of building a house is a terrible one and Lamport is just plain wrong. You would quite rightly expect disaster if you suddenly decided to add an extra bedroom while in the middle of building a house, or suddenly switch the front and back, or decide to add an extra storey. However analogous changes while developing software are really not a big deal. House-building requires physical objects to be assembled in a very precise way, ordered in time and space. Software is supremely flexible. By all means let's improve software engineering but stop bringing in completely nonsensical analogies.

Judging from the current code quality (0)

DaveV1.0 (203135) | about 2 years ago | (#42761391)

The "engineering" part of "software enginnering" has been a fantasy. If bridges were made at the same quality level as software, they would randomly collapse without warning for trivial reasons.

Does not matter for the short time code is useful. (0)

Anonymous Coward | about 2 years ago | (#42761405)

Buy the time it is hacked by the found security were on to ver 2 or the next big thing for most stuff think of all the old software you no longer use.
You must have cd and dvd full of it. and few of those are even the first version.

I am just saying rock on./ code on the ride has been great so far.

Taking it a tad too seriously. (3, Interesting)

bimozx (2689433) | about 2 years ago | (#42761417)

Seriously, anyone who takes "brogramming" as an epidemic really needs to question themselves. "brogramming" itself is already ridiculous and taking it seriously is even more ludicrous, why should anyone care if someone else define their activity as such. This is exactly the same problem with people perceiving that there are way more people being stupid than the old days. It's not that there is a sudden increase of people being stupid, it is simply because now, there is an outlet (the Internet) for them to be publicly stupid. There have been always, since the beginning, programmer being stupid, it is just recently that they have come to light. And there is no actual proof that "brogramming" actually has anything to do with turning good programmer into a bad one. At the end of the day, all that matters is a working code, does it even matter if the programmer is seemingly a jock or a nerd.

Brogramming more in line with business (1)

scamper_22 (1073470) | about 2 years ago | (#42761429)

Real software engineering takes a lot of time and a lot of resources. The closest I've heard of it is from those older workers who used to work for the old telecom companies back in the day. In my case Nortel in Canada. But even that was pretty far off.

They simply required a lot of resources in terms of people, time, equipment, and training.

Contrast that to 'brogramming'. New Idea... bunch of college kids whip out something usuable in a short time... get to market... deal with the rest of the stuff later.

The only way to protect against 'brogramming' would be to have software as a profession with standards enforced... like doctors, lawyers...

No (2)

Murdoch5 (1563847) | about 2 years ago | (#42761431)

I completely disagree with this post, I'm from the camp that you don't plan all the requirments before you start. I've done a lot of embedded and desktop programming and at least for me it's a far more productive setup to let the requirments fall out of the code as you work. I know many other programmers who would work better in this enviroment, we can see the requirments in the code and we have no problem seeing the end result as we work.

However I also know "old" programmers who work better where they want the bulk or all the requirments set before they start anything. Either camp is right, it just depends how you work, much like a great artist, you need to work in the way you best express yourself.

To sit someone down and plan requirements all out when they don't work that way is a huge waste of time, they aren't really getting much out of it and you've wasted time they could be programming. However on the same page to not plan the requirments out for someone that needs them will just hurt them. Hence I really don't think we need to move back to the view that requirments must be planned out, we need to move to a system where we reconize that some people work better in camp A and some in camp B. The industry needs to evolve with the times and it's in a state now where the young hot shots work differently but the old guys wants to resist change.

Bromancing the Brogrammer (4, Funny)

sl4shd0rk (755837) | about 2 years ago | (#42761441)

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

Programming is not Software Engineering (1)

sunking2 (521698) | about 2 years ago | (#42761447)

It's that simple. Thinking they are interchangeable to me tells me the true value of the end product. These wild west environments are allowed because in the end the products aren't all that important other than to generate money. And just like short selling a stock sometimes you win, sometimes you lose, but you understand and are willing to take the chance going in. If you want real Software Engineering practices you need to go to where the code actually matters. Like the auto/aerospace or anything else where there are tangible losses associated with failure.

I don't do a lot of programming (2)

mark_reh (2015546) | about 2 years ago | (#42761465)

but when I do (assembly language, PIC microcontrollers) I always start with diagrams that show the overall flow of the program, then I start making diagrams for the subroutines, etc. I generally have the whole thing diagrammed before I start writing any code and try to make subroutines as generic as I can so they can be reused easily. I thought this was how coding is done -it's how I learned about 30 years ago... are they teaching it different now?

gotta love (0)

Anonymous Coward | about 2 years ago | (#42761483)

This shit articles that the hype people love to write, about a trendy subject of the moment....... they suddenly become experts and write no matter the trend topic, and shit is born. Attention whores.

Nope... (2)

dohzer (867770) | about 2 years ago | (#42761487)

Bad management is killing engineering.
Next Question.

Not liked (0)

Anonymous Coward | about 2 years ago | (#42761489)

I personally didn't like the scene with drinking and programming.. They are looking for great programmers, Ok, I can get with that.. They want someone with personality.. Ok, I can get with that too.. But what if the person doesn't like the taste of beer/alcohol? does that mean they do not want them on the team?? Just sounds dumb. But I guess I just think society is better than that.. and of course.. wrong.

Weinberg's observation (2)

DaveAtFraud (460127) | about 2 years ago | (#42761583)

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.
Gerald Weinberg

Trivia: Gerald Weinberg is the "w" in awk. Sadly, things haven't changed much since back when.


Load More Comments
Slashdot Login

Need an Account?

Forgot your password?