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.
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.
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."
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.
this place needs an enima
... not houses. Software and houses are not similer.
Cool Story, Bro.
Brogramming is a joke already; get over it.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
As with all headlines formulated as questions.
Brokeback Mountain UML is the movie that should have you question 'brogramming.' Not that theres anything wrong with that.
"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".
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
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.
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.
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?
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...
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.
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.
Obliteracy: Words with explosions
Do you think Apple was made by strait-laced, sober people? They are "only and all hippies" and not "nerds".
When is this mythical creature supposed to have lived?
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.
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.
Code drunk, edit sober.
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
Rails Girls is for.
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."
Rich And Stupid is not so bad as Working For Rich And Stupid.
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.
No sigs in BETA. Beta SUCKS.
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"
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.
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.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
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.
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.
The only way to protect against 'brogramming' would be to have software as a profession with standards enforced... like doctors, lawyers...
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.
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!
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.
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?
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.
Bad management is killing engineering.
Next Question.
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.
Slashdot: It's like FOX news, but for liberals.
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
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 variables (I named the max and min current values c_max and c_min) or add "PC load Letter" and "ID 10 T error" to my error messages.
Knowledge = Power
P= W/t
t=Money
Money = Work/Knowledge so the less you know the more you make
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!
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
'Hogramming. Amiright fellas?
Foegramming. Not to be entered into lightly as the stakes are often YOUR LIFE!
Moegramming. Who let's these Stooges through the doors?
These jokes write themselves. Stop me. Please.
'Why we should build software like we build houses'
So the Hispanics are going to take over software development too?
Rick B.
The wired story was a rant disguised as news. I find nothing particularly new or useful in it.
My experiences of professional programming have been entirely different and what he describes.
I don't work for a game company and I generally don't work with children.
All the youngsters I've worked with aborted their careers with their bad behavior.
They don't put up with the stuff he rants about.
This terms seems to be being forced upon as to make a space in programming for the useless bschool mbas. FUCK THAT.
Worked for one of the largest IT companies in the world and it was imposble to get anything worthwhile done since it was all process and all tradition. Try to get something changed and people owuld fight you. Was not about the product or ends as much as it was just everyone working within the system.
Worked for a fast growing start up (30% growth, year after year after year). They are all about the individual hacker. We all shoot from the hip here and those who work the long hour and jump on the latest crazes for unique solutions seem to win. The process is every man for himself. It's imposible to get improvements done here too. People don't want to be told to do it certain ways or to work together.
Both were extremes and both suck to work for. In both cases on the surface people claim they want to improve the code base, improve the processes, and work together. In reality they just want to keep working the way they have been although for different reasons. The true of the matter is you need a mix of process, wild-west types, civlians, and a good sherrif to regulate it all. Too much leadership, too many who just keep their head down, or too many wild engineers and your product sufffers. Ballance is the key.
Both require some understanding of what's going to be done. Both require some experience to perform the actions necessary. Both are subject to failure. Both can be done well...which requires taking the title of this post and erasing it from memory. Building a high quality house is difficult as you need to account for possible additions, room changes, maintenance, etc. The same for software, to do it well you need to account for extension, alteration, and reduction...this is hard to do well. POCs work well to get the $$$ for doing it well. Make it fast, make it pretty, make it AWESOME!
There once was a brogrammer "Mo"
who coded with his friend from Slo'
Together they bro-ed, high fives to and fro
until both of them were let go.
This sounds like a bad thing, thanks god it doesn't fucking exists outside TFA and TFS. Now what does exist is bad a good programmers, just as always.
These jokes write themselves. Stop me. Please.
Stopramming. Don't look further.
Hey, my first job was in a brogramming environment. This was back in 2003 and it was a little company with young CS majors trying to do their 3 month job university credits, as the Education Ministry passed a "University-Workplaces bridging" directive making every single fucking student work for three months for free as an apprentice in various companies, otherwise you would not have gotten the credits required to publish your thesis. The problem is that the law helped fueling many tiny rubbish companies like that one, trying to sell them in the "widely expanding opensource sector with their e-commerce solutions".
After that stint I landed a real job for a real company working for the public administration, and no one else was brogramming. They used tons of technical documentation. I had a pile with all the requirements for the user cases I had to develop and to fix too, and I learned two things: first, requirements lie, second requirements lie because clients know jack shit of what they want. And they whine too. And if you catch them contradicting in e-mail instead of fixing your code yesterday, you are soon shown the door. Or rather someone else (not at the first big company but at the second) would go to a guy two desks farther away and make them implement the code that will eventually break the whole flow of application, like you predicted it would showing on the diagram what would happen with a big red marker.
After these experiences, I never found neither brogrammers nor uml cases, and nobody uses UML diagrams or software engineering practices, because they lead to make the client actually think about their software and their wishes. Behind all of this it's the idea that software development must be a mercenary discipline without the eventual shielding that real gun for hires get from their companies. And nobody in marketing or management wants that because, "what the hell, we have to keep our clients happy and shower them with PhD majors".
The brogramming environment? It was designed by the management, because they did not want to pay people. The no-uml environments? Software engineering at large failed because it does not scale well within most cultures. If software engineering does not infect your management then nobody will use it. > (Answer: because Office 6 and Windows 95 did not scale and were full of problems and gremlins until Microsoft adopted the engineering practices that they had in place for NT).
In any case, this is not the first time I've read articles against "developers". This pos of an article was linked by slashdot too: http://www.infoworld.com/d/application-development/6-home-truths-about-rockstar-developers-205098
I consider those shops where "just get it done", "hurry up", "we don't have time to refactor anything" producing the same results.
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
As someone who works in both fields, I think the house-building analogy is pretty good, but the author doesn't understand how houses are built.
An architect designs for functionality and aesthetics. Stability and safety are neither part of their job nor a significant part of their training. On a big job a structural engineer writes those specs. On a medium-size job the carpenter attempts to interpret the architect's design, while a building inspector has the final say. With smaller jobs or jobs on a budget, there's no place for an engineer or architect. Some building jobs are more aesthetic, others more critical. A bookshelf is not the same challenge as a kitchen. Doesn't the same apply to software? We need to distinguish between best practices and the rules of mere bureaucracy lovers. One doesn't generally hire an architect for a bookshelf.
So an architect is analgous to a UI designer, not a computer science engineer. Sometimes having a UI designer is important. Sometimes not. But a good house will require that all parties are honest and know what they're doing, whether there are upfront specs or not.
None of this has anything to do with "testosterone fueled" activity, any more than being supportive is caused by "estrogen poisoning".
Facebook was and is designed like crap and it works like crap. Lesson learned.
I haven't seen the movie in question, but if I understand you correctly, you're saying that if computer-y things worked like they did in the movies, it would be bad.
Does this mean I should turn off the beep that plays every time a character is displayed? And I should get rid of the "security override" button on my login screens?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The job of securing the resources of the computer is that of the Operating System, NOT application programmers. You should NEVER trust code outside of the OS. If you Linux fan boys could get your heads of out your collective ass and see that Linux isn't any better than Windows or Unix in terms of security because of the default permissive environment it's based on, we'd all get over this stupid meme of blaming users, Microsoft, capitalism, etc... and blame ourselves for having not seen the whole picture.
I hope and pray that Genode gets done enough to use in the next year or two.
You realise this is the male hormone, just like oestrogen is the female hormone? If it were a woman writing the code, would you be similarly quick to assign blame to her hormones when she fucks up?
If people code this way, it's not because of testosterone, it's not because they are men ruled by their hormones, it's because they are sloppy coders.
Bogtha Bogtha Bogtha
Though I hate the term "brogramming" and think it's completely stupid to try to program while drunk, I believe there is room for what used to be called the "heroic" model of software development in certain circumstances. The fact is that the technology world is fast paced, and often the product that becomes dominant (makes the most money) is not the one that's the most well engineered. It is the one that works well enough, has features people like, and makes it to the market first. A few very good coders with good domain knowledge and broad skills working heads down on such a project can absolutely run circles around (iterate faster) a large engineering team of siloed engineers focusing on requirements and architecture.
That is not to say that proper software engineering is dead... quite the opposite. In most industries and once a product reaches a certain size - quality, security, etc. are expected. You need a combination of good engineers and the right processes in place to make that happen. You cannot substitute processes for good engineers. As for waterfall vs agile... neither is perfect.... but Agile is better when requirements tend to change. It's bad to be dogmatic about either one though.
"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
Does anyone actually work like this in real life? Any business that has survived that is.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
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.
The reason you spend so much time placing requirements on a house is because a physical thing is hard to change, modify or move. A program is not a physical thing, a new one is a compile or less away. It is also significantly more complex. Using architecture as an example of how we should build programs is terrible because they are completely different things. This also ignores the fact that he is suggesting fixing cost overruns and quality issues of one industry by following the practices of an industry that is infamous for cost overruns and and quality issues.
"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.
Wrong Weinberg: *Peter* Weinberg did AWK. (See Wikipedia.) *Gerald* Weinberg is an IT consultant, not a hardcore programmer type.
Correction: Peter *Weinberger* (I left off "-er".)
"'Why we should build software like we build houses' "
Oh good god, if we built software the way houses are built than nothing would work. Houses start with a plan, but then fall apart right after that. you hire the cheapest contractor possible, they cut corners by buying B grade lumber and fudge things here and there. The architect NEVER comes back to make sure that the house is being built right. The plans are rarely followed. Electrician and HVAC just makes it work by cutting corners where they can.
In the end more attention is paid to the paint, carpet and countertops than the structure and infrastructure of the home. So it looks pretty, but is in fact a ball of hidden mistakes and covered up changes to cut corners.
Yeah, Wired needs to stop trying to be the Rolling Stone.
Do not look at laser with remaining good eye.
not Gerald Weinberg. Two completely different people.
you have the specs, but if you want exceptional code, at some point, you can only get that routine in your mind when youe drunk.
I have done my best assembly routines and recursions when relaxed, with a few drinks.
live long and code
"Editor's note: With widespread access to free, online coding courses and tools, “coding” has become the new writing – the everyman’s skill."
I really want this "anyone can do anything" cancerous ideology to die, as if availability is the cure to all that ails us. Quite frankly, writing is not an "everyman's skill" either, all you have to do to check the validity of that statement is to look at any comment thread. We sure don't see all those folks making a living as journalists, novelists and the like. Why some within the software industry promote "coding" literacy amongst the general public is absolutely beyond me. Doctors, lawyers, engineers don't espouse this, why do we?
I get where Lamport is going. What I don't like is the analogy (and others like "manufacturing" that get applied to software development, management of said projects, etc.) as, like all analogies, it dumbs everything down.
From an MBA / CEO perspective, if a) coding is an everyman skill and b) the construction of software is just like building a house (all you need is a blueprint), then it follows that anyone can build it. Sure, companies that follow this will fail, but will they know why? I'm pretty damn sure if your a hospital administrator who hired a doctor whose education amounts to "I stayed a Holiday Inn Express last night" and her patient dies, you have some sort of clue as to why.
Do we fully understand what we do when we dumb down our occupation with statements and metaphors like those above?
Don't even get me started on what Massive Online Courses do to us and how they devalue knowledge...
Brogramming is very different from cowboy coding. "Brogrammer" is a pejorative used to label developers that threaten one's ego by coming off as cool and social. In a development environment, many people aren't as focused on being "cool", so the term is necessary to raise yourself above those who do focus on that.
/. had a post several weeks ago associating the creative programmer with 'foreveralone' syndrome. I argued that the same could be said of artists (who can't maintain a health relationship with a significant other), and to some extent, it's a problem with the ego and creativity.
Abusing drugs and alcohol can be fun, but can only take you so far, just with artists or performers. You can get that creative "rush" while intoxicated, but as you professionalize, it helps you run the marathon of life. Most successful musicians and visual artists finally clamped down on their vices and disciplined themselves to work and created balance with fun. Those who keep going down the path of the so-called 'brogramming' is guaranteed to burn out. Just as with the other creative types.
AFAICT, that's a pretty spot-on analogy for how many software projects (particularly, large, contract-built business systems) are built now.
I currently work in a mission-critical environment. It's my first spec house and the cost of the software developed is easily 10-100x the previous places. The true problem with specs is that if you spend enough time developing them to be thorough, you've basically written the system in English (or whatever language you are working in). Human languages are incredibly vague and nuanced leading to arbitrary rules on key words and sentence structure. Then of course, if you create a spec, you probably create a design doc. Then the several customer/management driven changes come in and you now must rev one or more specs, a design document, the code and the tests. Given that time is finite, you end up having less time to focus on coding and testing.
This said, you shouldn't just hack a solution. If the problem is big enough you should spend time thinking about it and thinking about the design. Try a few iterations. Most importantly, find good devs. 1 good dev = 10-100 average devs. 1 bad dev = negative impact. Oh, and if you want to really make your software rock, employ a few more developers than you need. Find a few that are talented and proactive and you won't regret it. But as for specs, only write what you must and be happy with vague notions that are setup to serve as a guide. (I.e., "This system should support ~1,000 concurrent users" vs. "This system should support ~100,000 concurrent users")
I prefer "hogramming" personally.
Hog ramming?! Rather you than me, mate!
But I realized this whole story was completely fucking stupid and not worth putting any thought into.
Seriously, "brogramming"? Just fuck off.
I hope this Hollywood version of programming is as laughable as their war movies.
Builders may be able to build them, but I can guarantee you they haven't got a fucking clue what actually keeps them from falling down. Interesting, most architects don't know either. I suspect this is also the case when considering heating/cooling, and electrifying them as well, but those are not my specialty.
If you coded software like we build houses, you would never make an external call and every single routine would be accessed using GOTO.
Is it just my observation, or are there way too many stupid people in the world?
Just because everyone doesn't code like a pussy like yourself doesn't mean they aren't as good as you.
Lamport is a sharp guy, no question about it.
Unfortunately he, er, doesn't sound like he's worked in construction. In some/many construction sites. Blueprints are liable to simply not work, the roofers are hungover, and the sheetrockers, well, they got As on their drug tests, if you know what I mean. Change requests from the architecture come in asking for some fruity recolorization all the time, along with whining about how they really didn't want the wotsit in the middle of the room. The engineer is trying to make the architect come down to reality, while the actual workers think both are on poofy-ooffy clouds of unrealism and stupid.
Software 'engineering' is already like house construction. And that ain't a compliment to either.
I'm SO glad for allll those people who learned everything they know about how to make computers work from watching movies and reading articles like these. Yeah, I agree, IT'S FUCKING DUMB.
"Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
After several years, you can become a true Broftware Engineer. Or, if you're more customer oriented, a Senior Brogram Manager.
still awaiting for sisgrammed estrogen and pink cola powered kinky codes. none available.
"brogramming" will kill programming, the same way DUI's will kill Nascar.
Can someone make up a term for one who constantly searches google for the best solution? That's what I am.