Is 'Brogramming' Killing Requirements Engineering? 432
chicksdaddy writes "Veracode's blog has an interesting piece that looks at whether 'brogramming' — the testosterone- and booze-fueled coding culture depicted in movies like The Social 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!"
Brogramming??? (Score:5, Insightful)
Can we fucking kill this meme right now?
[John]
Re:Brogramming??? (Score:5, Insightful)
Judging from some of the roofers I've known, drunk would be exactly the way to "build software as we build houses".
Re: (Score:3)
This is why roofers are responsible for the orderly arrangement of asphalt squares and not something delicate and precise like nailing two pieces of wood together...
Re:Brogramming??? (Score:5, Funny)
I've seen many fights on slashdot in my time, but "carpenters vs. roofers" is a new one on me.
Re: (Score:3)
Re: (Score:3)
Re:Brogramming??? (Score:5, Funny)
Re: (Score:3)
Plumbers are the ones with the lead pipes, so be careful what you say, punk!
Re: (Score:3)
Re:Brogramming??? (Score:5, Funny)
I don't know why were are bringing roofers into this in the first place when a perfectly good car metaphor is probably waiting to be used.
Re: (Score:2)
they are afraid of heights dude
Re:Brogramming??? (Score:5, Funny)
If houses are code, I think I found Perl [all-that-i...esting.com].
Re:Brogramming??? (Score:5, Insightful)
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)
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
Re: (Score:3)
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?
Re: (Score:2)
I remember when we called this sort of thing "cowboy coding."
Now I feel so old, I'm imagining there were actual cowboys.
I think this refers to something completely different... I have a lot of respect for some cowboy coders. I can't imagine having the same respect for a "brogrammer".
Re: (Score:2)
Napoleon Bronapart and Broan of Arc both support your efforts.
Re: (Score:2)
Re:Brogramming??? (Score:5, Interesting)
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)
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)
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.
Re: (Score:3)
Of course there is a beer culture, they use yeast to make it.
(Slightly more seriously, searching wikipedia for beer culture actually has a result: http://en.wikipedia.org/wiki/Beer#Beer_and_society [wikipedia.org].)
Re: (Score:3)
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
Re:Brogramming??? (Score:5, Funny)
I clicked that article and there is a image with the word scrogrammer. If that's the alternative, I suggest we just stop using words to describe things.
Re: (Score:3)
Re: (Score:2)
Bro, do you ecen code?
Re:Brogramming??? (Score:5, Insightful)
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).
Re:Brogramming??? (Score:5, Funny)
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...
Re: (Score:3)
I once had a well gnarly problem to solve. After dithering and pondering and putting it off for a couple of days I had a four Duvel lunch and solved it in what was left of the afternoon. It was good, too.
Now "beyond a certain point" is vague to say the least. But I was certainly in no fit state to drive.
Re:Brogramming??? (Score:4, Funny)
Well, if you're legitimately drunk, your body has ways to shut that whole thing down.
Re: (Score:3)
Prototyping (Score:5, Interesting)
Brogramming is prototyping.
In the ideal project, you gather the spec in advance, carefully design, and then implement.
In the real world, almost everything is a prototype because the demands are not known. Your product may succeed for entirely different reasons than you expected. At that point, you're going to be re-coding. Once you present a prototype, people will have changes that are more than cosmetic. You're going to "hack" -- literally kludge around the expected design -- and force it to work.
At that point, you have a prototype. The correct response then is to go back and refactor everything to make rev2.0 a solid and powerful piece of software.
This doesn't apply in every case. If you've got a clear task that's more technical than business/social, you can draw it all up on paper and build it the way L. Lamport suggests.
But for the rest of us, 'brogramming' is just another way of saying "getting to rev1.0"
Re: (Score:3)
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)
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...
Re: (Score:3)
Brogramming is prototyping.
Yes, because prorotyping is best done in a booze and testosterone fueled haze.
Re: (Score:2, Funny)
There's a certain urgency, determination, and focus that just isn't there at other times.
These days, I do a line of coke once in a while for a similar effect but it's not the same thing.
Re: (Score:3)
And that's OK for things where security doesn't matter like Facebook or Google. But not for banks, medical devices, airplane controls, military ...
Re: (Score:2)
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
Re: (Score:3)
Re: (Score:2)
ftfy. and truth be told we all do prototyping, but we (the good ones at least) step back after the prototype is done and think long and hard about throwing all the code away in favor of doing it the right way.
Only to then get a big fat "NO" from management because "it already works fine".
Handling management (Score:4, Insightful)
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.
Re: (Score:2)
Never seen one (Score:5, Insightful)
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.
Re:Never seen one (Score:4, Funny)
Obligatory:
Hey girl, the only way you're gonna keep my stack from overflowing is if you dereference my pointer. [tumblr.com]
The equestrian pattern (Score:5, Funny)
I read that as "Why we should build software like we build Horses"
But then I am drunk at work today.
Depends on the product (Score:5, Insightful)
If you was your time upfront and someone beats you to the market, who cares about the engineering!! If you capture the market for a new idea you can use a more formal process for v2 while your competitors missed out.
If you are building my pacemaker, then lets be formal from the start!!
Seems, dumb to make a one size fits all statement about hacking out some code vs. engineering.
Re:Depends on the product (Score:4, Insightful)
If you was your time upfront and someone beats you to the market, who cares about the engineering!! If you capture the market for a new idea you can use a more formal process for v2 while your competitors missed out.
Just like MySpace beat FaceBook to market and Netscape beat IE to market. Getting that first mover advantage really fueled their meteoric rise and long stay at the top.
Re: (Score:2)
If you was your time upfront and someone beats you to the market, who cares about the engineering!! If you capture the market for a new idea you can use a more formal process for v2 while your competitors missed out.
Just like MySpace beat FaceBook to market and Netscape beat IE to market. Getting that first mover advantage really fueled their meteoric rise and long stay at the top.
pretty shitty examples considering that lack of specs killed neither MySpace or Netscape(we're still using specs netscape came up for lot of stuff aren't we?) and neither FB or IE were written exactly to any spec originally....
with a pacemaker you know what the thing is supposed to do and within what parameters. with coming up something like facebook they didn't.
Re: (Score:2)
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"
Re: (Score:2)
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.
Oh look, a buzzword (Score:2)
Let's hope all this bro-gramming doesn't result in a coding-gate!
That's why you see a lot of crap code (Score:2)
Re: (Score:2)
And you are sure it can't be alcohol?
We should build software like we build software (Score:3)
Re: (Score:3)
Definitely. But to be fair, we should make floating point operations like we make house-building operations, because the return values both have floors and ceilings.
Re: (Score:2)
Software and houses are not similer.
While software and houses are not similar, you could use building a house as a simile for building software, so in that way they are "similer". (I think you just made up a new word.)
That said, I think the point they are making is that you should have a plan before building a house and you should also have a plan before building software, and not just jump right in.
Re:We should build software like we build software (Score:5, Funny)
Software and houses are not similer.
Of course they are.
For one thing, when people ask an architect to design a new home for their family, it's perfectly normal to call him back six months later in the middle of first fit and say that actually what they need is a skyscraper. With a secret underground lair. And access to open water, so unfortunately the urban site where half of it currently sits is no good and the whole thing will need to be relocated to the nearest coast. And the building regs have suddenly changed, so now instead of concrete and rebars, the whole thing has to be made of environmentally friendly engineered wood materials.
Moreover, just like houses, we have thousands of years of experience building software now. We've become pretty good at telling in advance which techniques will be needed, what order the different components will need to be built in, and especially estimating how long it's going to take and what it will cost.
Actually, maybe it is a slightly unfair comparison, because the amateurs who build physical structures, like that mile-long railway tunnel that was drilled from both ends and wound up out of position by absurd amounts like 4mm when they met in the middle, can't really keep up with software development professionals who can build precisely specified interfaces and get everything to fit together exactly on the first attempt.
That's mostly because the tools and processes for doing all of this in the software world are well understood throughout the industry, which in turn is because everyone practising software development has gone through rigorous training taught by people who are themselves experts with years of practical experience to draw upon. Engineers and architects try to do the same thing, but they just haven't quite nailed it yet. I guess software guys have an advantage here because those tools and processes are universal and uncontroversial, so everyone in software does things the same way and software project managers don't really need to co-ordinate their team to quite the same extent that, say, a lead contractor would when building a house.
But apart from that slight advantage because software development is so much better understood, I think it's perfectly reasonable to compare building a house to building software and expect things to work the same way. There's really no qualitative difference at all, and basically the same processes work just as well for both tasks.
Brogramming was a joke (Score:2)
he doesn't know the history (Score:2)
"writing software" – free form, creative, inspirational – from "software engineering," its older, more thoughtful and reliable cousin.'
Bullshit. The free-form, creative, inspirational kind is decades older than "software engineering".
Re:he doesn't know the history (Score:5, Interesting)
Take a look at his biography [veracode.com]. His experience starts mid-90s in large corporations. Maybe he thinks computing started then?
Re: (Score:2)
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!
Re: (Score:2)
Re: (Score:2)
Agreed.
I don't know where that comes from, but it's total bullshit, plain wrong, and should never come from somebody writing an article about programming.
Well, as another reply to my post pointed out, his bio is online, and shows that he got his start in the mid-90's in large corporations.
Like houses??? WTF?? (Score:5, Insightful)
Anyway as a software engineer I can tell you that I THINK in code. I draw diagrams sometimes, for the complex bits, as necessary. But if I code up a POC and it sucks, it's cheap to tear it down and start again. Not so much when you are building a house, get it right the first time or you will hate life. So it's a dumb analogy.
Re:Like houses??? WTF?? (Score:5, Insightful)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Conversely (Score:3)
Or why we should not build software like houses (Score:4, Funny)
Good software means much more. It requires honesty, integrity, empathy, even a talent.
Requirements Engineering? (Score:4, Insightful)
"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...
mythical creature (Score:2)
When is this mythical creature supposed to have lived?
Re: (Score:2)
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
That's because coding and design are different (Score:3)
The superstar programmers are the ones who are adept at both roles, but the run of the mill coder is not a super star. and the run of the mill designer hasn't gone much beyond do-while loops in an introductory Java class. Separate out the analysts from the programmers, treat them like the two roles and two separate skill sets that they are, and you'll produce better software all around.
Pure Fiction (Score:2)
The closest you'd come to seeing this in reality might be a group programming project at a university.
Re: (Score:2)
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
Somebody's gotta do it (Score:5, Informative)
Fluff article... (Score:4)
....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)
Bad code... survives (Score:2)
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 Article (Score:2)
House-building is a terrible analogy (Score:2)
Taking it a tad too seriously. (Score:3, Interesting)
Brogramming more in line with business (Score:2)
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
No (Score:3)
However I also know "old" programmers who work better where they want the bulk or all the requirments set before they start anything. Either camp is right, it just depends how you work, much like a great artist, you need to work in the way you best express yourself.
To sit someone down and plan requirements all out when they don't work that way is a huge waste of time, they aren't really getting much out of it and you've wasted time they could be programming. However on the same page to not plan the requirments out for someone that needs them will just hurt them. Hence I really don't think we need to move back to the view that requirments must be planned out, we need to move to a system where we reconize that some people work better in camp A and some in camp B. The industry needs to evolve with the times and it's in a state now where the young hot shots work differently but the old guys wants to resist change.
Bromancing the Brogrammer (Score:5, Funny)
There was once a brogrammer from Slo
who coded with a bro named mo
together they flowed, to and fro
until they were both let go
Programming is not Software Engineering (Score:2)
I don't do a lot of programming (Score:3)
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?
Nope... (Score:2)
Bad management is killing engineering.
Next Question.
Weinberg's observation (Score:3)
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
Programming Drunk (Score:2)
Re: (Score:3)
I named the max and min current values c_max and c_min
Oh I love it when you talk dirty
Doesn't matter (Score:2)
Is this forced culture (Score:2)
This terms seems to be being forced upon as to make a space in programming for the useless bschool mbas. FUCK THAT.
the real reason houses don't collapse.... (Score:3)
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.
Yes and no (Score:3)
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.
Re: (Score:3)
pot, meet kettle :)
See the second picture [stackexchange.com] on the first answer. Notice how the waterfall system as described by the original inventor shows how it iterates backwards until the major steps are completed. Surprised that waterfall isn't quite as waterfall-y as popular fable suggests?
The problem with the 80s/90s waterfall led projects were external to the methodology used. The concept of up-front design can work, if you understand you need to be a little bit flexible. I'd say there are a lot of projects today th
Re:Why should we care? (Score:5, Insightful)
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.
Re: (Score:2)
Yeah, men enjoying things with men is now gay. Next, testosterone will be oppressive, and castration preferred. Give it a rest.
Re: (Score:2)
You can beat them, but you must then endure the ritualised taunting of the camper. Gaming culture strongly discourages that style of play because it can ruin the fun: If everyone does it, no-one ever moves anywhere. Camping only works fun-wise for everyone on maps designed so the camping spots are good, but not too good: You need the snipers to at least poke their heads into the open, not shoot through a hole exactly large enough to see through.