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!
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.
If you was your time upfront and someone beats you to the market, who cares about the engineering!! If you capture the market for a new idea you can use a more formal process for v2 while your competitors missed out.
If you are building my pacemaker, then lets be formal from the start!!
Seems, dumb to make a one size fits all statement about hacking out some code vs. engineering.
Anyway as a software engineer I can tell you that I THINK in code. I draw diagrams sometimes, for the complex bits, as necessary. But if I code up a POC and it sucks, it's cheap to tear it down and start again. Not so much when you are building a house, get it right the first time or you will hate life. So it's a dumb analogy.
-73, de n1ywb
www.n1ywb.com
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...
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.
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.
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...