Forgot your password?
typodupeerror
Programming Security

Is 'Brogramming' Killing Requirements Engineering? 432

Posted by Soulskill
from the made-up-words-you-already-hate dept.
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!"
This discussion has been archived. No new comments can be posted.

Is 'Brogramming' Killing Requirements Engineering?

Comments Filter:
  • Brogramming??? (Score:5, Insightful)

    by Bigbutt (65939) on Friday February 01, 2013 @11:11AM (#42761001) Homepage Journal

    Can we fucking kill this meme right now?

    [John]

    • Re:Brogramming??? (Score:5, Insightful)

      by Anne_Nonymous (313852) on Friday February 01, 2013 @11:14AM (#42761039) Homepage Journal

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

    • Re:Brogramming??? (Score:5, Insightful)

      by telekon (185072) <canweriotnowNO@SPAMgmail.com> on Friday February 01, 2013 @11:18AM (#42761093) Homepage Journal

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

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

      • Re: (Score:2, Insightful)

        by 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 agai

        • by Raenex (947668)

          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.

          Sounds like you just do a half-assed job and expect a "code monkey", or more realistically, a professional, to fix up after you. Let me guess, you're a consultant?

      • by N0Man74 (1620447)

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

    • by JLavezzo (161308)

      Napoleon Bronapart and Broan of Arc both support your efforts.

    • Re:Brogramming??? (Score:5, Interesting)

      by gl4ss (559668) on Friday February 01, 2013 @11:29AM (#42761263) Homepage Journal

      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??? (Score:5, Insightful)

        by AwesomeMcgee (2437070) on Friday February 01, 2013 @11:58AM (#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??? (Score:5, Interesting)

        by Austerity Empowers (669817) on Friday February 01, 2013 @12:00PM (#42761617)

        This. Only this, nothing but this.

        I work in a place where people drink beer (and other things, but don't advertise), and I haven't noticed a great amount of crazed free-form coding. In fact reading their software list these guys are complete nazi's about code, in style, format and architecture. I have begun to think the beer is the way for them to chill out enough not to throttle each other because they placed a { in the wrong place.

        Previously, we had no Wall Street executive representation, just company founders who wanted the product to work properly and build out. But to secure funding, we had to let in a Wall Street bot, and he's busy managing things to pieces. No doubt he feels the beer culture is behind people's schedule issues and general non-compliance with his ridiculous goals. But the fact is he's destroying their product with management, trying to force them to write bad code based on schedules not design.

        I'd also like to point out that "bro-culture" and "beer culture" are not necessarily related. One can drink beer and not be a "bro". We have a "bro" or a "browannabe", and he's actually quite a competant coder, but generally speaking the rest of the beer culture are not bro's at all.

      • by sjames (1099)

        This 1000 times! Managers don't want to see developers sitting quietly and thinking. They don't want to see them sitting and talking in the corner. The don't want to see people drawing funny diagrams. They want to see them grinding out code like little interchangeable cogs.

        On the contractor side, clients for some reason think the spec should be free and want to pay only for delivered code. If you don't want to go broke by delivering >90% of the effort up front for free only to see the paying part go to t

    • by Anonymous Coward on Friday February 01, 2013 @11:34AM (#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.

    • by identity0 (77976)

      Bro, do you ecen code?

    • Re:Brogramming??? (Score:5, Insightful)

      by TheSpoom (715771) <slashdot@@@uberm00...net> on Friday February 01, 2013 @12:21PM (#42761851) Homepage Journal

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

      • by Frosty Piss (770223) * on Friday February 01, 2013 @01:20PM (#42762425)

        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.

        That's because they are generally too busy doing lines.

        Of code. Lines of code...

    • by Synerg1y (2169962)
      I'm also scratching my head... how is "The Social Network" related to coding? Those were fuckin actors??? Coders have coded in teams since the start of coding, whether in the workplace, or in a garage, it's to bounce ideas off each other, and get help with bugs and techniques, is it possible to drink after coding... or fuck it, it's a choice, not a meme.
  • Prototyping (Score:5, Interesting)

    by concealment (2447304) on Friday February 01, 2013 @11:13AM (#42761023) Homepage Journal

    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"

    • by gbjbaanb (229885)

      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" nonsen

      • Re:Prototyping (Score:4, Insightful)

        by AwesomeMcgee (2437070) on Friday February 01, 2013 @12:17PM (#42761803)
        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...
    • Brogramming is prototyping.

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

      • Re: (Score:2, Funny)

        by Anonymous Coward
        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.

    • by Skapare (16644)

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

    • by Creepy (93888)

      case in point
      TCP/IP vs OSI

      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

      • by jandrese (485)
        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.
  • Never seen one (Score:5, Insightful)

    by Anonymous Coward on Friday February 01, 2013 @11:14AM (#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.

  • by fatgraham (307614) on Friday February 01, 2013 @11:15AM (#42761041) Homepage

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

    But then I am drunk at work today.

  • by cs668 (89484) <cservin@cromagnon.com> on Friday February 01, 2013 @11:15AM (#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.

    • by schlesinm (934723) on Friday February 01, 2013 @11:21AM (#42761135) Homepage

      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.

      • by gl4ss (559668)

        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.

      • by cs668 (89484)

        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"

      • I see it a little differently than you. MySpace was huge, but mismanaged entirely. That makes it a completely different issue.


        Basically, both were services that did similar things, but they were in different "generations" even though only separated by a few years. They weren't competing head to head from the gate.

        It wasn't like there was a race to market that Myspace won and Facebook lost. Facebook literally got to sit back and look at all the things MySpace did wrong and do it differently themselves.
  • Let's hope all this bro-gramming doesn't result in a coding-gate!

  • 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."
  • ... not houses. Software and houses are not similer.
    • by telekon (185072)

      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.

    • by invid (163714)

      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.

    • by Anonymous Brave Guy (457657) on Friday February 01, 2013 @11:57AM (#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 is a joke already; get over it.
  • "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".

    • by h2oliu (38090) on Friday February 01, 2013 @11:43AM (#42761433)

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

      • by sribe (304414)

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

        You, sir (or madam), have solved the mystery. Unfortunately, I can offer neither riches nor fame for this :-(

        Hell, I can't even mod you up!

    • If it makes you feel any better I don't think they meant "older" as software engineering" has been happening longer than "free bla bla bla". I think that it is similar to when you go to a family reunion and you see two cousins where one just dropped out of high school (even if just too smart to be there and didn't give a shit) and the other, older and "wiser", that has plowed through and just finished his MS in Comp Sci. The second is viewed as more reliable and more thoughtful. Even though his actual age h
  • by n1ywb (555767) on Friday February 01, 2013 @11:25AM (#42761185) Homepage Journal
    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.

    • by sandytaru (1158959) on Friday February 01, 2013 @11:35AM (#42761335) Journal
      Actually, your description of that new house is exactly like some code I've seen...
    • by endus (698588)

      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

    • by drinkypoo (153816)

      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 wit

    • Software is not like a house.

      Software project management is very much like construction project management. I even know a person with a PhD in construction project management who went into software project management for medical software.

      Show a developer who's under the gun for a project deadline and is getting last-minute changes thrown at him daily how change orders work in construction, and he'll either laugh or cry at his own situation. That developer is *not* in a mature environment, but he is in a v

    • "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." -Gerald Weinberg
  • by Max_W (812974) on Friday February 01, 2013 @11:25AM (#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.
  • by hsmith (818216) on Friday February 01, 2013 @11:26AM (#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...
  • 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?

    • by Haxagon (2454432)

      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 se

  • by sandytaru (1158959) on Friday February 01, 2013 @11:27AM (#42761223) Journal
    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.
  • 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.
    • 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.

      I've done some coding in my career. Sometimes it was 100% of my job. And the only time I ever did (or saw) anything that could be remotely termed "brogramming" was as a teenager, when my friends and I traded off creating the most obnoxious version of a BASIC program to print our names over and over on a display model C=64 in the local Venture* store. (I believe the "winner" of that contest was the guy who POKEd in alternating rainbow pattern text and background colors.)

      "Brogramming" bears about as much simi

  • by king neckbeard (1801738) on Friday February 01, 2013 @11:34AM (#42761329)
    obligatory xkcd [xkcd.com]
  • by MrNemesis (587188) on Friday February 01, 2013 @11:34AM (#42761331) Homepage Journal

    ....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 (Score:5, Funny)

    by RedHackTea (2779623) on Friday February 01, 2013 @11:35AM (#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.
  • 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

  • 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.
  • 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 me
  • by bimozx (2689433) on Friday February 01, 2013 @11:41AM (#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.
  • 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.

    Th

  • by Murdoch5 (1563847) on Friday February 01, 2013 @11:43AM (#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.
  • by sl4shd0rk (755837) on Friday February 01, 2013 @11:44AM (#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

  • 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 wh
  • by mark_reh (2015546) on Friday February 01, 2013 @11:46AM (#42761465) Journal

    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?

  • Bad management is killing engineering.
    Next Question.

  • by DaveAtFraud (460127) on Friday February 01, 2013 @11:58AM (#42761583) Homepage Journal

    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.

    Cheers,
    Dave

  • What is wrong with programming drunk, at two or three beverages you are considered drunk. On a Friday with a deadline approaching nothing helps calm the nerves like a few beers. I do some masterful work when I have a beer or two in me. It seems like having a beer or three is lumped in with getting frat boy drunk and programming. Shitty code comes from shitty programmers with shitty standards, about the only thing I will do differently when I'm programming while drinking is sneak in a few lewd names for var
  • Have worked in that kind of environment as well as Prince II (waterfall) and Agile/Scrum they all have their strong points. Just let the Team decide which one they want don't force it down their throats. Also I agree with the 1st Post I don't want to hear/read etc the term Brogramming ever again!
  • This terms seems to be being forced upon as to make a space in programming for the useless bschool mbas. FUCK THAT.

  • by tilante (2547392) on Friday February 01, 2013 @01:12PM (#42762347)

    Building software like houses sounds nice, but it overlooks the real reasons that houses don't collapse: (1) How to build them is well-known. We've been doing it for literally thousands of years. (2) The people who build houses have to be licensed. This helps ensure that they know how to build them properly. (3) Mandatory house inspections mean that if someone builds a house without following accepted standards, they'll have to prove that it's actually safe to occupy.

    Most importantly, though, when a house collapses, it's visible. The people living in it complain loudly. The neighbors see it and talk about it. It makes the news. And then, people don't want to hire whoever built that house. They get investigated. There's a good chance they lose their license. That's the big difference - our culture has come to expect broken software. "It's not a bug, it's a feature." "Oh, there's a workaround for that." "Yeah, that doesn't work in the version." "Oh, that crashes all the time. Just restart it."

    If we treated broken software like broken houses - with astonishment, complaints, investigations, and penalties - software developers would do better. They'd have to. Of course, the reason we don't is that the consequences of broken software generally aren't nearly as serious. Sometimes, they are - but generally not.

  • by EmperorOfCanada (1332175) on Friday February 01, 2013 @01:18PM (#42762407)
    "Brogramming" (horrible term) and highly engineered programming are both great solutions to different sorts of problems. The key in choosing which is how well mapped out is your destination. If you are building a banking system where customers will engage in known transactions resulting in a known data stored in the database then the backend of this system obviously demands a very carefully engineered solution. But for that same solution the front end should be pretty damn freeform. People should try a bit of this and a bit of that feeling their way to an awesome UI. The back end engineering will dictate what data needs to come in from the UI and what data needs to go out but a great UI comes from a combination of requirements, gut feelings, fiddling, artistic balance, etc.

    Then after the UI is ready for polishing you might go back to a more engineering approach and try AB testing where you watch the speed at which a user uses the system along with other measures such as number of mistakes.

    Personally I find that people who hate the free form programing tend to be those managers who just don't trust their employees. They want to lay everything out in a design document that then locks everyone into a my-way-or-the-highway approach. This is a great way to get your best programmers to find another company to work for. Also my best programming has come from those times that I went down 5 dead ends and the 6th was really cool. But the 6th naturally evolved from what I learned in the first 5. There is no way that it would have ever have been conceived in a design phase.

    There are many things that can cause inertia that are not directly related to the code. A simple example would be unit testing. (I love unit testing) but if you are going to completely redo your system then much of your unit testing goes out the door. Your carefully written documentation is garbage. Your design documents are all garbage, and any work you have done in planning version 2 or more is trashed. This makes drastic alterations much more costly than just the programming. But the reality is that you should never produce a bad product because the paperwork got in the way of switching it to a good or great product. This is sad because often if all that needs alteration is the UI where a well engineered code base should have fairly good UI abstraction and thus a new UI should involve little fundamental/programming work.

    Really which is used and when it is used comes down to great managers. They will focus the freeform programming on organically finding cool ideas while not chasing rainbows and at the same time making sure that the fundamentals are well engineered. Within any team of programmers there are usually those who prefer one or the other anyway.

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Working...