Slashdot Mirror
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.
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.
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
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.
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...
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.
Occasionally living proof of the Ballmer peak.
pot, meet kettle :)
See the second picture 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.
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.
....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.
Moderation Total: -1 Troll, +3 Goat
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
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.
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.
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!
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.
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:
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.
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
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." -Gerald Weinberg
When someone says, "Any fool can see
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.
"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.
I named the max and min current values c_max and c_min
Oh I love it when you talk dirty
+1 Disagree