Is Agile just a justification for bad business practices?
-
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
I am suprised to hear you say that. Maybe you're in an environmemt where agile is be applied differntly than the way I use it. Where I work Agile means work closely with business to develop soultions through iteration. This allows me to serve in many roles. I do my own BA and Architect work as well as writing the code and devoping the data model.
-
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'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes. In my limited experience. Obviously your mileage differs. Stuart
-
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
Actually having one architect (or a group) act like god, design everything up front and hand it off to mindless programmers sounds like turning developers into cogs. Actually it sounds kind of like CMMI 5 and waterfall. My experience is that many of the agile principles are useful, not because they are called agile, but because when we practiced them 20 years ago they worked well. Our highest priority is to satisfy the customer. Deliver working software frequently. Build projects around motivated individuals. Face-to-face communication is best. Working software is the primary measure of progress. Continuous attention to technical excellence and good design. Simplicity (maximizing the amount of work not done) is essential. I don't care whether you call those principles agile or poop, they work when I use them.
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've made it fairly clear that Agile development borrowed existing concepts and called them their own. (For example, Agile did not invent iterative development and staged releases whatsoever.) My broader point I've been making is that simply using parts of Agile methodologies is NOT doing Agile development. By this definition, I've been doing Agile development for all 39 years I've been programming. If you aren't using the Agile process in its entirety, then you aren't doing Agile development. (Likewise, if you claim to do to XP programming "except the pair stuff" then you simply aren't doing XP programming and to claim so is being extremely disingenuous.) A big problem with arguing this is that the vast, vast majority of engineers who talk about Agile development, don't actually know what it actually insists on. They've long picked and chosen those portions which work for them and then make their claims.
Anna-Jayne Metcalfe wrote:
or indeed are engaged in "playing" at agile, as the team you describe seem to have being
This is the standard line proponents of every hair brained scheme claim. Ironically, you openly admitted that you don't use all of Agile development, so why claim those that have are the ones "playing" and thus their negative results are invalid?
Joe Woodbury wrote:
I've made it fairly clear that Agile development borrowed existing concepts and called them their own. (For example, Agile did not invent iterative development and staged releases whatsoever.) My broader point I've been making is that simply using parts of Agile methodologies is NOT doing Agile development. By this definition, I've been doing Agile development for all 39 years I've been programming. If you aren't using the Agile process in its entirety, then you aren't doing Agile development. (Likewise, if you claim to do to XP programming "except the pair stuff" then you simply aren't doing XP programming and to claim so is being extremely disingenuous.) A big problem with arguing this is that the vast, vast majority of engineers who talk about Agile development, don't actually know what it actually insists on. They've long picked and chosen those portions which work for them and then make their claims.
First of all Agile itself isn't really a process - it is a set of principles. Scrum, XP, Lean etc. are all agile processes simply because they adopt those principles, but each implement them in a different way (XP has pairing, Scrum has stand up meetings etc.). Each stands on its own merits and has its own strengths and weaknesses (as does the process we use, of course). None are definitive (e.g. Scrum has recently been criticised because it doesn't focus sufficiently on technical quality, something which XP does rather well), but all are evolving over time. If you ever meet any of big names in quality and process (e.g. Tom Gilb, Niels Malotaux, Tom and Mary Poppendieck etc.), you will find that virtually all of them are singing from the same hymnsheet (it's all agile principles and PDCA - Plan-Do-Check-Act). That in itself is remarkable enough, given the history our industry has of failed software projects. Arguably, learning enough to evolve your own process from core principles is healthier than following a fixed process blindly without understanding it. Hence I'd contend that it doesn't really matter which bits of which processes you pick, so long as you do so in an informed fashion, and are prepared to change how you do things as you gain experience. The fact that the principles we follow are agile is because we've learnt they work. If BUFD had worked out, no doubt we'd be doing a customised version of that instead (but it didn't, did it...?). If you're not convinced, come along to the
-
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:
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 wouldn't expect a nurse to manage a hospital nor a teller to manage a bank. I would expect someone with experience managing people and projects (both) could very well do better than someone with no experience at either even if that latter person works in the industry. But far as I can recall I have never seen anyone managing a software project at the detail level that didn't have experience in the industry. At some level going up there is eventually going to be someone asking when it is going to be done who doesn't code. I say that because with very, very few exceptions I wouldn't want any software developers that I have worked with to be responsible for insuring that sales happen. And at the end of the day I would rather get paid then deliver the latest project on time.
-
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.
led mike wrote:
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.
That however can be said about many of the methodologies.
-
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 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 know of projects that failed due to many reasons using various methodologies. And there are many reasons for rationalizing failure. And little evidence that success of a project depends on methodologies unless it is followed rigorously There is also evidence that projects, of all sorts, have a better chance at succeeding when the programmers are better. I seriously doubt that particular result doesn't apply to most human endevours.
-
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
John C wrote:
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. ... 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 $$$.
If I need brain surgery I believe that I would prefer the good brain doctor versus the one that is so-so. Doesn't matter what technique each doctor uses. The same applies to what you said. If you have a small group of good practitioners the fact that you are successful is much more likely based on the fact that you are good rather than due to the particular processes that you use.
-
I'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes. In my limited experience. Obviously your mileage differs. Stuart
smacmartin wrote:
I'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes.
I don't see anything in that that doesn't apply to any correctly implemented methodology.
-
Actually having one architect (or a group) act like god, design everything up front and hand it off to mindless programmers sounds like turning developers into cogs. Actually it sounds kind of like CMMI 5 and waterfall. My experience is that many of the agile principles are useful, not because they are called agile, but because when we practiced them 20 years ago they worked well. Our highest priority is to satisfy the customer. Deliver working software frequently. Build projects around motivated individuals. Face-to-face communication is best. Working software is the primary measure of progress. Continuous attention to technical excellence and good design. Simplicity (maximizing the amount of work not done) is essential. I don't care whether you call those principles agile or poop, they work when I use them.
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
All of your points with the exception of "deliver working software frequently" and "build projects around motivated individuals" (which is just wishy washy "newspeak" because surely no organization is going to be stupid enough to carry unmotivated individuals are they?) fall firmly into the GOES WITHOUT SAYING category, at least in this shop. I firmly disagree with building any application of any consequence or import piecemeal. All that accomplishes is crappily designed software that makes the gray men in suits happy because it fits the costs into nice quarterly budgets. It's clearly going to be far more expensive to produce and it encourages lazy design. Obviously no big application is ever done so there is always a need to roll out changes but in my world you better have every last bit nailed down on new projects before a line of code is ever written. Then again in my current world we can't pass on the costs to the unsuspecting customer since we sell our software commercially and don't do any contract programming for single customers.
"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
-
All of your points with the exception of "deliver working software frequently" and "build projects around motivated individuals" (which is just wishy washy "newspeak" because surely no organization is going to be stupid enough to carry unmotivated individuals are they?) fall firmly into the GOES WITHOUT SAYING category, at least in this shop. I firmly disagree with building any application of any consequence or import piecemeal. All that accomplishes is crappily designed software that makes the gray men in suits happy because it fits the costs into nice quarterly budgets. It's clearly going to be far more expensive to produce and it encourages lazy design. Obviously no big application is ever done so there is always a need to roll out changes but in my world you better have every last bit nailed down on new projects before a line of code is ever written. Then again in my current world we can't pass on the costs to the unsuspecting customer since we sell our software commercially and don't do any contract programming for single customers.
"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
So by your own admission, most of the agile principles are valid. The reality is that there are considerable numbers of "programmers" that are only doing it for the money, and don't care about customers interests/needs the way you do. The "deliver working software frequently" may be just another way of saying "nightly builds", or getting software to testers early so they are not getting dumped on with the whole package two weeks before it is due. In my industries the customers minds change so often that if you built to the original requirements they would never accept it. If I can nail them down to accepting one piece at a time, I get a lot less surprises and a much happier customer.
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
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question. ;P
-
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question. ;P
dmitri_sps wrote:
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question
Although that might be true, I can only note that the other formal methodologies are almost universally not followed as well. Most companies either do nothing or do so little that no one realistically suggests that they are following any methodology. Other companies claim adherence and yet examination shows that they are in fact not following the methodogies - they implement some of the easiest practices in a ship-shod fashion and completely ignore the harder ones (which actually produce the most bang for the buck.) There are of course some companies that do implement some formal methodology correctly. But the number is so low compared to total developement numbers that it is effectively zero.
-
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
>And in the asinine category: > >1. do just the minimum to get the functionality in >2. refactor often (or something like that) Just wondering what has led you to this conclusion?
-
dmitri_sps wrote:
This "we don't need no education" manifesto was born by dot-com boom, when fresh graduates flooded start-ups, with the only "business plan" just to do something, which could be sold later. Later it clicked with management for all the wrong reasons, which you well described in your rhetoric question
Although that might be true, I can only note that the other formal methodologies are almost universally not followed as well. Most companies either do nothing or do so little that no one realistically suggests that they are following any methodology. Other companies claim adherence and yet examination shows that they are in fact not following the methodogies - they implement some of the easiest practices in a ship-shod fashion and completely ignore the harder ones (which actually produce the most bang for the buck.) There are of course some companies that do implement some formal methodology correctly. But the number is so low compared to total developement numbers that it is effectively zero.
jschell wrote:
the other formal methodologies are almost universally not followed as well
I do not see this as a problem. Among successful companies, as you correctly mentioned, there are some who do it by the book, and more are made successful by competent managers and professional developers who do not follow any formal methodology, as they are past a need for a textbook. And similarly different are the loosers in IT world - both who try to follow some methodology on paper, and those who do not have a clue. The later bunch, when they found out that there is such thing as "agile" methodology, gladly jumped on it, just as the Dilbert cartoon (quoted somewhere in previous replies) depicted so well ;)
-
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 think Simons response is about the most balanced of those I have seen here. No, in itself Agile is not simply a justification for bad business practices. On the other hand, I've seen plenty of organisations that use the term as an excuse not to plan. No-one would spend a million dollars on a new high rise building without a fairly comprehensive plan. Having said that, no-one would expect that plan to go down with the level of specifying where every individual nail will be placed. Plenty of people seem to attempt to write software with those extremes of planning though.
Good advice is always certain to be ignored, but that's no reason not to give it.
-
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 in its complete form is very far away from "bad business practice", problem is that hardly anyone ever uses it in its complete form (I have never seen it used in its complete form). By definition: - an Agile project does not produce less documentation, it is in fact suppose to produce more (updates & re-iterations MUST be documented well) - an Agile approach is not to complete a project faster, its to ensure that when a project is completed it delivers on the customer's (user) needs, and is important in environments where needs change quickly - an Agile project needs FAR more management time, BA time and User time, and decreases developer time. Managing of changes and scope is crucial for sustainable IT - an Agile project is not cheaper than other approaches (clear from above) - an Agile project needs FAR more dicipline, from all parties involved including management, BA's, developers AND the customer (this is where the wheels usually comes off) - Agile is not intended for massive projects, it can work for massive projects if segmented well though but care should be taken If Agile is done correctly its very effective, just like using a hammer to smack nails with, if the right tool is used in the right way by the right person for the right purpose the results are impressive...
____________________________________________________________ Be brave little warrior, be VERY brave
-
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 think it's a bit to simply stated. Admit it, or not, but most software designers either aren't capable to estimate development time accurately if they're given a detailed design. And, even if there is a proper design, the as-built end product is often not really what was designed. There's what I'd call the 'design paradox'. On one hand, you can't estimate costs accurately, if you're design isn't detailed enough. As a result, the details will be designed while coding, design flaws will creep in and that causes a lot of additional debugging. On the other hand, if the design is very detailed, in theory this would lead to less bugs, and a better manageble project, but in real life many "bugs" will be built into the design already, because what looks nice on paper, might not work in a real program. And we all know it's virtually impossible to correctly estimate the time involved in finding the cause of a bug. So having or nog having a detailed design mostly means moving the problem from one end of the project to the other: the 'law of conservation of misery'. So we have to find a compromise between detailed design and hands-on programming. Several things have been proposed in the past. In the mid-'90s, RAD was promoted, now it is Agile. At first sight, Agile looks as if it's just throwing ingredients into the pot, hoping something edible will emerge. But then we overlook a few things. Agile is not only about taking the product the market sooner, it's also about collaboration with the customer and even better, with the end user. To many end users, a detailed design of a complete product is too abstract to comprehend. That's where the communication problem starts and in the end the software turns out not to be doing what the user wanted. Agile tries to address this, by shortening the design/develop/test/deliver cycles. The idea is not to leave out design, but not to design all at once in detail. Personally I'm convinced you'll always need an overall picture, a 'grand design', but that doesn't mean you have to design everything in detail upfront. To some extent, it is what we've been doing all the time already - or rather, should have been doing all the time: start to make a rough design of what we want and then refine it. Tradionally, all of this was done by the designers, but Agile aims to get the end user involved. The way to accomplish this the Agile way, is to refine a basic number of features, build them and present them to the user for evaluation. I don't expect anyone to dispute that if that turns out
-
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!
Manager: I don't care what it looks like, just make it work. Then you deliver the first version and most of the comments are to do with what it looks like! :laugh:
Kevin
-
>And in the asinine category: > >1. do just the minimum to get the functionality in >2. refactor often (or something like that) Just wondering what has led you to this conclusion?
Andrew Napier wrote:
Just wondering what has led you to this conclusion?
Because I see people writing code without any thought to even a minimal amount of abstraction or consideration for good practices (for example, implementing some of the more common patterns.) A little thought ahead of time would save on refactoring later. And it really isn't a balanced equation. Putting the effort up front in writing good code is a lot less expensive than fixing it later. Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner