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
-
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
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.
-
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
Pardon my shouting, but HURRAY! I believe you've hit the proverbial nail on the proverbial head. Sales and marketing believe that engineering refuses to build products they can sell at a time when the market for a given set of features is 'hot'. Engineering believes that sales and marketing have unrealistic expectations of the time required to build that given set of features.
Software Zen:
delete this; -
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. 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
-
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 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
-
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.
Because everyone views software as this abstract amorphous blob, that isn't anything that you have to take very seriously (until it doesn't work, doesn't get built, or doesn't do what you expected it to do). Because there's no physical "thing" you can touch, people just don't take it seriously. At least that's how it seems to me.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
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, I think you have to be careful that agile doesn't just become "lets not do any design" like the 'marketing/bad business people' want, but instead agile is recognising that doing all your design up front isn't necessarily the best thing because you discover new things as you go along that you could never have realised from the beginning. I'm not talking about changing requirements, I'm talking about the fact that half way through your project you discover that your design doesn't quite fit and you need to make changes. One of the things about agile that I do really like is the idea of "release early and often". This way you keep your client informed of progress, and get instant feedback so you don't go off in the wrong direction too far if something has been misunderstood. (By release, I don't necessarily mean full access release to the client, but some form of release to testing, or release as a sample of what's been done so far) Fixed requirements are still important, and lots of design is still important. Most methodologies seem to preach "their way" as the perfect path, but ideally I think you need to take the best from all of them without religiously adhering to any one. Different projects have different characteristics and priorities. If you follow any specific one too strictly you won't be flexible when the project isn't going exactly as the methodology allows for.
Simon
-
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
Christopher Duncan wrote:
Nonetheless, I just have to ask, isn't Agile just a justification for bad business practices?
Lots of teams without any plan at all often call themselves "agile", jumping on every new idea that enters the room. That doesn't mean that the Agile practice is a bad one. From the manifesto (also posted in that thread)
From the manifesto:
Individuals and interactions over processes and tools
Well, they got a point there. Lots of shops focus on their golden hammers and silver bullets, and not on their employees and their capabilities.
From the manifesto:
Working software over comprehensive documentation
I'm still struggling to understand this point, so I'm skipping commenting this one :)
From the manifesto:
Customer collaboration over contract negotiation
Another good point; It's better to collaborate with the customer than to hit him/her around the ears with the text "we agreed on this, and we'll build this!".
From the manifesto:
Responding to change over following a plan
You gotta have a plan Stan. You can respond to change and update the plan. Impulsiveness without direction is kinda dangerous. Lots of teams will use a mix of practices, I doubt that there will be much people who follow them rules blindly like religious zealots. Nothing replaces common sense, and that's what most of these practices are - a list of common sense-idea's.
Going to bike home agily :)
-
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 has been an open Joke at large companies for a long time now. Management uses it for justification for ad-hoc development. I suppose the real question is not, "Is Agile just a justification for bad business practices?" but "Is company X, whose development is in shambles who claims to be using Agile actually using Agile?" The answer, I think, would be shocking to those outside the loop.
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
-
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
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.
-
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
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|WTL -
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
Being in the learning stages of various software development approaches, I'll not attemp an argument against what you have said, rather, ask your opinion of authoritative sources I have been following lately. Iconix's "Use Case Object Modeling with UML" by Doug Rosenberg and Matt Stephens and "Agile Development with Iconix, People, Process and Pragmatism" by same guys. I draw the conclusion that small/quick or beta releases must at least have had some designing (possibly revising earlier ones), implementation (obviously), and verification testing (unit, system, etc.) before heading out the door.
Christopher Duncan wrote:
we've created an official methodology for this process, we feel better about it.
My personal feeling is that successful software development can be more attainable if the organization establishes its standards and practices with a quality management system (eg. adheres to CMMI). This serves as a surrounding support framework around your chosen software development process(es). Yes, even one that has short increments for release.
-
Because everyone views software as this abstract amorphous blob, that isn't anything that you have to take very seriously (until it doesn't work, doesn't get built, or doesn't do what you expected it to do). Because there's no physical "thing" you can touch, people just don't take it seriously. At least that's how it seems to me.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
Jim Crafton wrote:
until it doesn't work, doesn't get built, or doesn't do what you expected it to do
Exactly, that's what I say to my managers all the time. They are constantly saying that "they" don't care about this that or whatever and I always respond with, "Right they don't care... until they do". The point of that response is that later when they do care, it's TO FRAKIN LATE YOU IDIOT!
-
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.