Is Agile just a justification for bad business practices?
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
There is nothing wrong with Agile. Most people don't implement Agile, they (and we do this where I work) use their own *cough* process (code and fix) based on all the wrong things and claim to be following Agile. The fault is with the people (like always), not Agile.
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
Yes! Yes! YES! Agile is also a way bad engineers can hide. I personally don't know a single successful project that used Agile development. Not one. Yet, I know many that have failed. In one, the astonishing thing is that the manager, engineer and designer responsible for the fiasco were rewarded while everyone else either quit or was fired (for questioning the Gods.) I figure that in their twisted little brains the triad convinced the management fools that had everyone else didn't really do the Agile method properly; that's why it failed (not because they sucked at management, engineering and design and were just making crap up as they went along.)
-
I don't know what it is and I haven't time to read your rant, but the fact that you actually had the time to write it brings the answer to my mind: YES, AGILE = BAD BUSINESS PRACTICE! ;P You're the proof!
You have a little bit of brown stuff on your nose.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
Done right it's good, done wrong it's bad; same as with anything.
-
Most of the time, the deadline and available resources are already known when the request for an estimate is made, so the estimate is at best being used to select among candidates, or as a starting point for negotiating a "better" estimate (i.e shorter for substantially the same scope). This is a silly game, which really should be replaced with a simple query: "can we deliver a quality product with this minimum acceptable feature set by this deadline with these resources?". As you observe, agile just formalizes a perpetual beta process. That said, there is value in an iterative (but possibly not agile) development process provided it is not also an excuse for hasty and incomplete design.
Rob Graham wrote:
That said, there is value in an iterative (but possibly not agile) development process provided it is not also an excuse for hasty and incomplete design.
very true! And iterative development process is not quite new, and existed well before the agile term was coined.
You can't turn lead into gold, unless you've built yourself a nuclear plant.
-
Yes. There's the short answer. :)
Christopher Duncan wrote:
It seems to me that before you can build something, you have to know what it is and how you're going to go about building it.
I've never worked with any client that new exactly what they wanted. Partly because they're also re-inventing their work processes at the same time. Sort of like mixing gasoline and fire, but that's the nature of the beast. I've essentially been practicing Agile for 20 years, before it was called Agile. The pieces that work for me are: 1. communication between team members in daily stand-up meetings / phone calls 2. putting the app frequently in front of the client so they can alter the course 3. unit testing, if you have the time and the client has the budget (reality bites) What Agile doesn't cover, IMO, is: 1. analyzing the cost of "altering the course" 2. updating the documentation so you have a record of what you changed and why 3. renegotiating the contract when changes occur And in the asinine category: 1. do just the minimum to get the functionality in 2. refactor often (or something like that) [edit] Oh, and the only way I've gotten Agile to really work is to take a declarative approach to programming. Separate the declarative from the imperative, and your development process becomes, by defacto, more agile. [/edit] Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
Marc Clifton wrote:
Separate the declarative from the imperative, and your development process becomes, by defacto, more agile
WPF! WPF! WPF!
You can't turn lead into gold, unless you've built yourself a nuclear plant.
-
You have a little bit of brown stuff on your nose.
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
SCRUM, Agile, Water Fall ... BAH! Those are for the weak. We use AD&D Design Methodologies. Savings Throw verse New Project Dead-Line. :rolleyes:
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTLDouglas Troy wrote:
We use AD&D Design Methodologies.
I am the guardian and keyholder of the coke machine, so get the **** back to work!
I wanna be a eunuchs developer! Pass me a bread knife!
-
Yes! Yes! YES! Agile is also a way bad engineers can hide. I personally don't know a single successful project that used Agile development. Not one. Yet, I know many that have failed. In one, the astonishing thing is that the manager, engineer and designer responsible for the fiasco were rewarded while everyone else either quit or was fired (for questioning the Gods.) I figure that in their twisted little brains the triad convinced the management fools that had everyone else didn't really do the Agile method properly; that's why it failed (not because they sucked at management, engineering and design and were just making crap up as they went along.)
Joe Woodbury wrote:
Agile is also a way bad engineers can hide.
I've found it to be the reverse. Using scrum iterations soon shows who the load-bearers are, and who isn't contributing.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Christopher Duncan wrote:
Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front.
I think the root of the problem is not a development process (agile or not) but the fact that in many organizations people with no background in software development somehow think they can manage software projects. I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Software management is easy. It all boils down to a few menu options and some dialogs! :doh:
Todd Smith
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
If the developer doesn't devote any time to the design phase then it's a failing on their part imho. You have to assume that Marketing and other business types will ask for the moon and expect it delivered yesterday. It's our responsibility to push back and impress upon them the need for design. That doesn't mean go full waterfall but you need to make sure you're not setting yourself up for some kind of trap down the road. disclaimer: Not all projects are created equal so your mileage may vary.
Todd Smith
-
Christopher Duncan wrote:
Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front.
I think the root of the problem is not a development process (agile or not) but the fact that in many organizations people with no background in software development somehow think they can manage software projects. I am not sure what is it about software development that make everybody think it is easy to manage. I know I would not dare to manage a hospital, for instance, or a bank.
Nemanja Trifunovic wrote:
or a bank.
Managing a bank is easy: 1. Don't go public, so you don't have stupid stock holders who are only interested in short term immediate gratification 2. Don't take government money 3. Invest your customer's money wisely and with low risk 4. Don't get involved in hairbrain lending schemes 5. Treat your customers like gold ;) Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
Marc Clifton wrote:
Separate the declarative from the imperative, and your development process becomes, by defacto, more agile
WPF! WPF! WPF!
You can't turn lead into gold, unless you've built yourself a nuclear plant.
Pierre Leclercq wrote:
WPF! WPF! WPF!
Erm...no. :) Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
I've worked waterfall, I've worked agile - they can both work fine. The thing to remember is that "No Big Design up front" != "No design up front". Agile still implies architectural design, user requirements (== user story) analysis and a lower level of more detailed design.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
I've worked waterfall, I've worked agile - they can both work fine. The thing to remember is that "No Big Design up front" != "No design up front". Agile still implies architectural design, user requirements (== user story) analysis and a lower level of more detailed design.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Agreed. My experience is that if you have access to users/customers, design when needed (iterative design) works well because you can get a piece done, verify it is what is needed, then concentrate on the next piece. Designing the whole product completely often results in lots of redesign or unused design, once you realize what the customer really wants after a few iterations of showing the product.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
Please read the Agile Manifesto and Principles agilemanifesto.org/principles[^]. Whilst what you describe may well be how many people are experiencing development, it doesn't match the clearly stated goals of agile. Agile done properly, as with most things, works extremely well.
-
Please read the Agile Manifesto and Principles agilemanifesto.org/principles[^]. Whilst what you describe may well be how many people are experiencing development, it doesn't match the clearly stated goals of agile. Agile done properly, as with most things, works extremely well.
That's like saying read the bible, it has all the answers and is crystal clear. That is why we have unlimited versions of christianity, each of whom is convinced they are right. That is also why Agile people seem to claim failures as "you just didn't do it right". My problem with Agile is that it claims to be all things to all people mostly by being completely unspecific. This allows the bad business processes to be propagated because Agile will equally say do design if you need it, don't do design if you don't need. If you have been failing in a process, then any process change could help. I think Agile has been successful "rescuing" people who were failing. Since their is no head to head comparison, there is no way to really now what made it successful. I think there are many cases where Agile is a very poor fit. And I have personal experience with switching from a working process to Agile where it decreased output, productivity and quality. That being said, trying to do a full end to end design up front is a bad idea. Doing little or nothing, for any system beyond the most simple, is a really bad and expensive idea. Unfortunately, this is how Agile is often interpreted.
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
SSDD Blueprints! Blueprints! We don't need no stinkin blueprints! Start building all three stories. Now. We can dig the foundation later. I'll be back tomorrow to see how it's coming along... Flash forward 3 weeks: Ok. We want to make the 2nd bedroom on the third floor bigger by 25 sq ft without altering the size of the ground floor. And can you change that roof. Client doesn't like gray shingles. Forward 3 more weeks: We don't want a second floor any more. Take it out. ...what? I don't care that it's got plumbing and wiring going to the third floor. Make it happen! Forward 6 months after 1000 more "adjustments": Looks great from the outside, but I gotta tell ya, the inside REALLY sucks... There are rooms with no door, stairs that lead nowhere, and what's with that bay window in the shower? Why is this taking so long? Forward 3 months: Client pulled the plug. They bought someone else's house. Way to go. You're an idiot. --------------------------------- Good. Quick. Cheap. Pick any two!
Cheers, Mike Fidler
-
I was reading Simon's post[^] about how his boss told him to "release early and often" but wanted a bottom line number on when the project would be done, and it got me thinking. Every so often there's a new darling design methodology of the day, which becomes the gospel for the religious for however many years it takes for some ivory tower sort to come up with the next one. I've been through many in my career, from waterfall to structured A/D to the fragmented camps of OOA/D, ad nauseum. Of course, no shop I've ever seen does the analysis & design 100% by the book, performing every recommended step in the process, because management never wants to allocate time to analysis & design. The typical business mentality is that if you're not coding, you're not making progress, and so any attempt to take the amount of time that's really necessary to figure out the what and the how is squelched by the pressure of arbitrary deadlines. "How long will this take?" is usually asked after "This is when we're planning on releasing the product." In other words, the loudest voice against doing a thorough analysis and design up front is not the developer who thinks it's a bad idea, but the businessman who simply doesn't want to take the time. That's the way it's always been, at least in my 20 years in the industry. From waterfall to OOA/D, the problem was never that they were bad methodologies, but simply that they took more time to perform than the businesspeople wanted to allow. ("How long will it take to build this log cabin?" "Well, first we have to cut down the trees..." "We don't have time to cut down the trees. Just build the darned thing!"). Fortunately, Agile comes to the rescue by telling businesspeople exactly what they want to hear. You don't have to do all that pesky thinking up front. Just come up with a half baked idea, slap it together and you'll have a release. Crappy quality or not what you wanted? No problem. Agile anticipates this, allowing you to repeat this cycle as often as you like and feel good about the fact that you're using an Official Design Methodology. It seems to me that before you can build something, you have to know what it is and how you're going to go about building it. However, nobody wants to hear that, so we've come up with a design methodology based not on the sensible solution of thinking b
Agile like so many other things is simply a method to commoditize development and turn us developers into cogs in a machine which are easily replaceable or outsourced. Why developers continue to embrace this stuff that is a) stupid and b) directly antithetical to having a stable and well paying career as a software developer will remain one of the great mysteries of the universe. The dirty secret I believe is that it doesn't matter which methodology you follow as long as you have one be it "official" or whatever you know works for you.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
Agreed. My experience is that if you have access to users/customers, design when needed (iterative design) works well because you can get a piece done, verify it is what is needed, then concentrate on the next piece. Designing the whole product completely often results in lots of redesign or unused design, once you realize what the customer really wants after a few iterations of showing the product.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
Jim (SS) wrote:
Designing the whole product completely often results in lots of redesign or unused design, once you realize what the customer really wants after a few iterations of showing the product.
I disagree. There is a huge penalty in wasted man hours when a project is *not* designed as much as possible completely in advance. We are a very small shop and we get big things done because we can't afford to fart around with each crappy new ideology that comes down the pipe. I think your perception is muddied by the amount of resources that can be thrown at it. What you are describing is actually committing code based on early customer feedback, that is completely unnecessary in this day and age, an entire app can be mocked up with all the important bits and in fact there are far too many lazy development teams that don't take the vital step of transforming what the customer wants into what the customer actually *needs*. A good architect can take the customers wants and turn out and app that is half or less the size of what a lazy shop can turn out. In turn that smaller app is more intuitive to the end user, accomplishes more with less effort and saves them big $$$. The rush to market and risk averse attitude that is prevalent today is what is resulting in so much crappy software despite every over thought design methodology in the world now at our fingertips.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg