3 ms·

"The agile push came people who were reacting against creating pages of useless design up front documentation" er, what? The agile push came from people who sa

"The agile push came people who were reacting against creating pages of useless design up front documentation" er, what? The agile push came from people who saw an opportunity to make money [1]. To understand that you need to understand both the advantages of waterfall, it's disadvantages, and how those disadvantages were mitigated. Documentation is but a single (and pretty minor) aspect of it. The biggest single issue with waterfall is also is biggest advantage - segmentation (what Barry Boehm called segments or stages of a project). Stages follow each other sequentially. Requirements analysis follows inception, design follows requirements analysis, development follows design, test development, and so forth. The advantage is that it is predictable (ironically, agile's biggest disadvantage). It's disadvantage is that it's crazy expensive to reverse the sequence, i.e. go from test back to dev, from dev back to design, and so on. The mitigations back in the early 80's were to prototype (fail fast) and to turn a single protracted release into many smaller releases (what became known as the spiral model) - aka fail often. In amongst all of that TDD happened, and someone decided to turf documentation because everyone hates doing it anyway. eXtreme programming came along and gave protyping and iterative releases a shiny new badge. Pair programming wasn't for everyone, so someone removed that, added daily standups and gave it a shiny old name (scrum was first applied to product development in the early 80's and formally documented in '86[2] - it was nothing like what it is today). Oh, and modern agile processes contract release cycles even more. Note that there are other intrinsic (requirements almost always missing/incomplete, stages produce communication gaps, and as you mention, documentation) and extrinsic issues (it's a pm methodology, not a dev methodology) with waterfall. [1] http://www.infoq.com/articles/agile-teenage-crisis http://www.infoq.com/articles/agile-teenage-crisis [2] https://www.wittenburg.co.uk/Entry.aspx?id=dce9dde8-d770-47c2-ad66-937cfabadb59 https://www.wittenburg.co.uk/Entry.aspx?id=dce9dde8-d770-47c...

litmus 13y ago
"The agile push came people who were reacting against creating pages of useless design up front documentation" er, what? The agile push came from people who saw an opportunity to make money [1]. There are only four items in the Agile Manifesto. The second item specifically highlights documentation cost overhead of traditional methods as a major grievance: "Working software over comprehensive documentation" (see also [1]). I don't think money is a differentiating factor, we're talking about the software business in the end after all. If you're referring to process snakeoil marketing, I'm against that no matter which side is doing it. I was responding to your assertion that software developers go from "agile" to "design up front" as they "grow up". My view is that the people that began popularizing the agile term were in fact "grown up" programmers. Are we talking about different things when we talk about design? What is the output of "design up front" in the traditional sense if not documentation and diagrams? (for example, see the military standards and ISO standards for what's required for detailed design) I don't see anything objectionable in the descriptions you give, although I don't view the waterfall process as being predictable in any meaningful sense. Its only predictable in so far as its underlying assumptions hold. And in the software world at large such assumptions (fixed unchanging requirements for example) rarely hold. My claim is that circumstances for the space shuttle software is the exception, not the rule. [1] http://davidfrico.com/rico08e.pdf http://davidfrico.com/rico08e.pdf
- Spearchucker 13y ago
  Seems we're not really disagreeing about the reality. We do seem to have different... interpretations, maybe? "The second item specifically highlights documentation cost overhead of traditional methods as a major grievance" Comprehensive documentation may be a major grievance, but it is pales in actual impact on the organisation, team or project when compared with the extortionate cost of discovering a design error during the test phase. "Are we talking about different things when we talk about design?" Two answers. First one is yes, I think we're talking about the same thing. Design in the sense that I use it is system design, or architecture. And yes, in a waterfall world that output typically is documentation + diagrams. Second answer? Design how I do it doesn't involve documentation at epic war-and-peace proportions. A diagram can be very useful when communicating complex designs to external (to the team) stakeholders. A one-pager with VLAN descriptions and IP addresses can be helpful to a pen tester. However, in my world it's about a plan - - What's the availability target, and how will it be met? - Is the database relational, document-based, or are we using a lambda architecture? Justification? - What's the dev plan? I.e. what feature dependencies exist, and how will they be prioritised? Consider for example a client app that communicates with a USB device. Initially a simple web site might be enough, but ultimately you need to choose between a native app; a daemon that bridges USB and browser via HTML websocks, or a daemon that bridges USB and browser via web site. "although I don't view the waterfall process as being predictable" It is extremely predictable in that phases are sequential, and you know exactly which skills are required for each phase. You'd use a business analyst to elicit requirements, and you'd not use a tester to write code. That means you can schedule resources across projects horizontally, instead of leaving them on one project until complete. You mention "in any meaningful sense", and you're very, very correct to include that. The point is that waterfall is just as efficient at delivering quality code quickly as any modern agile methodology is. What's required is an experienced team. Consider that an inexperienced team will screw up on an agile project just as much as they would on a waterfall project. Here's an analogy (taken from a blog post I'm still working on): -- Karate is a martial art. It is also a competitive sport, and has strict rules. Krav Maga is street fighting. Anything goes - no rules, no competitions. I've been doing Krav Maga for over four years, and think it's the best self defence system known to man. Saying that Krav Maga is the best is interesting. Not because it really is the best, but because that statement demonstrates two important things: - It demonstrates consistency - my desire to be (and appear to be) consistent with what I have already done. Once we've made a choice, we encounter personal and interpersonal pressures to behave consistently with that commitment. - It ignores reality - my girlfriend, a 3rd Dan black belt, has been doing Karate for over 18 years. Whether Krav Maga is better than Karate on not is immaterial - she'd kick my arse from here into next week. The reality is that she's simply more experienced. No matter how brutal a counter attack in Krav Maga is, she's so fast that there's no way I can even block her attack (I know because we spar). -- It's that concept of experience that I refer to when talking about devs/hackers/programmers growing up. As devs/hackers/programmers I think it serves us well to understand both extremes (waterfall and agile), and move the slider between the two as required. The mix should be appropriate for the team's experience. Enough prescriptiveness from waterfall to coach where coaching is needed, and enough agile to ensure that mistakes don't become expensive. Common sense should not be ignored when dealing with documentation, TDD, pair programming and the like, and nobody should ever be elected scrum master just because they paid someone for a piece of paper saying they can do it.

litmus 13y ago

"The agile push came people who were reacting against creating pages of useless design up front documentation" er, what? The agile push came from people who saw an opportunity to make money [1]. There are only four items in the Agile Manifesto. The second item specifically highlights documentation cost overhead of traditional methods as a major grievance: "Working software over comprehensive documentation" (see also [1]). I don't think money is a differentiating factor, we're talking about the software business in the end after all. If you're referring to process snakeoil marketing, I'm against that no matter which side is doing it. I was responding to your assertion that software developers go from "agile" to "design up front" as they "grow up". My view is that the people that began popularizing the agile term were in fact "grown up" programmers. Are we talking about different things when we talk about design? What is the output of "design up front" in the traditional sense if not documentation and diagrams? (for example, see the military standards and ISO standards for what's required for detailed design) I don't see anything objectionable in the descriptions you give, although I don't view the waterfall process as being predictable in any meaningful sense. Its only predictable in so far as its underlying assumptions hold. And in the software world at large such assumptions (fixed unchanging requirements for example) rarely hold. My claim is that circumstances for the space shuttle software is the exception, not the rule. [1] http://davidfrico.com/rico08e.pdf http://davidfrico.com/rico08e.pdf

Spearchucker 13y ago
Seems we're not really disagreeing about the reality. We do seem to have different... interpretations, maybe? "The second item specifically highlights documentation cost overhead of traditional methods as a major grievance" Comprehensive documentation may be a major grievance, but it is pales in actual impact on the organisation, team or project when compared with the extortionate cost of discovering a design error during the test phase. "Are we talking about different things when we talk about design?" Two answers. First one is yes, I think we're talking about the same thing. Design in the sense that I use it is system design, or architecture. And yes, in a waterfall world that output typically is documentation + diagrams. Second answer? Design how I do it doesn't involve documentation at epic war-and-peace proportions. A diagram can be very useful when communicating complex designs to external (to the team) stakeholders. A one-pager with VLAN descriptions and IP addresses can be helpful to a pen tester. However, in my world it's about a plan - - What's the availability target, and how will it be met? - Is the database relational, document-based, or are we using a lambda architecture? Justification? - What's the dev plan? I.e. what feature dependencies exist, and how will they be prioritised? Consider for example a client app that communicates with a USB device. Initially a simple web site might be enough, but ultimately you need to choose between a native app; a daemon that bridges USB and browser via HTML websocks, or a daemon that bridges USB and browser via web site. "although I don't view the waterfall process as being predictable" It is extremely predictable in that phases are sequential, and you know exactly which skills are required for each phase. You'd use a business analyst to elicit requirements, and you'd not use a tester to write code. That means you can schedule resources across projects horizontally, instead of leaving them on one project until complete. You mention "in any meaningful sense", and you're very, very correct to include that. The point is that waterfall is just as efficient at delivering quality code quickly as any modern agile methodology is. What's required is an experienced team. Consider that an inexperienced team will screw up on an agile project just as much as they would on a waterfall project. Here's an analogy (taken from a blog post I'm still working on): -- Karate is a martial art. It is also a competitive sport, and has strict rules. Krav Maga is street fighting. Anything goes - no rules, no competitions. I've been doing Krav Maga for over four years, and think it's the best self defence system known to man. Saying that Krav Maga is the best is interesting. Not because it really is the best, but because that statement demonstrates two important things: - It demonstrates consistency - my desire to be (and appear to be) consistent with what I have already done. Once we've made a choice, we encounter personal and interpersonal pressures to behave consistently with that commitment. - It ignores reality - my girlfriend, a 3rd Dan black belt, has been doing Karate for over 18 years. Whether Krav Maga is better than Karate on not is immaterial - she'd kick my arse from here into next week. The reality is that she's simply more experienced. No matter how brutal a counter attack in Krav Maga is, she's so fast that there's no way I can even block her attack (I know because we spar). -- It's that concept of experience that I refer to when talking about devs/hackers/programmers growing up. As devs/hackers/programmers I think it serves us well to understand both extremes (waterfall and agile), and move the slider between the two as required. The mix should be appropriate for the team's experience. Enough prescriptiveness from waterfall to coach where coaching is needed, and enough agile to ensure that mistakes don't become expensive. Common sense should not be ignored when dealing with documentation, TDD, pair programming and the like, and nobody should ever be elected scrum master just because they paid someone for a piece of paper saying they can do it.