• Nick Radov (unregistered)

    This editorial seems to be based on flawed assumptions. If you're just building yet another pyramid, then sure it makes sense to do the design work ahead of time and then implement it in a methodical way. The "pyramid" problem has been solved several times before, perhaps on a smaller scale, and the basic issues are well understood.

    Where agile really becomes necessary is when you are trying to build something innovative that no one has done before. In that case you typically only have a vague concept of what the final requirements will be and can't predict ahead of time what the optimal design would be. So you just have to get something, anything running. That allows you to explore possibilities, get feedback, and understand the limits of new tools.

    Once you have built a piece of software with an agile methodology, you then have to circle back to refactor the design. This is where the analogy with constructing physical objects completely breaks down. If you have a real pyramid, you obviously can't go inside and move around the interior stone blocks. But with software you can (and must) refactor the internal modules so that below-average developers can cope with later maintenance. Sometimes agile gets a bad name because developers never get around to that refactoring step, so they finish the project with something that sort of works but is a complete mess inside.

    The really important point is that you have to adapt the methodology to the project. Sometimes agile is the only feasible option. Other times it will lead to disaster. A skilled project manager knows how to choose.

  • (cs) in reply to RadiantMatrix
    RadiantMatrix:
    Good developers write quality software (by definition). If a shop moves to Agile, it needs fewer overall developers, which means it can afford for all of its developers to be good. That is, as long as that shop is willing to invest in those good developers up front.

    The problem with Agile is the opposite of the problem with RUP -- RUP provides some protection from bad developers, but also can prevent good developers from doing their best; Agile allows good developers to do their jobs effectively, but doesn't protect against bad developers.

    Au contraire:

    • Pair programming drastically reduces mistakes made by bad programmers in new code and helps them become better
    • Extensive unit tests reduce likelihood of bad programmers breaking stuff
    • Constant refactoring means that crappy code has a better chance of getting fixed
  • Poltras (unregistered) in reply to gwenhwyfaer
    gwenhwyfaer:
    JamesKilton:
    The problem with our industry, as I see it, is that anyone can program.

    No, the problem is that programming is really fucking hard; and if you look at those people who are acknowledged as the best programers, they're generally the ones who acknowledge that, are all too aware of their own inadequacy for the task, and do whatever they can to mitigate that. What great programmers don't do is go around complaining that everyone else isn't good enough...

    I think I saw something on this forum about it, along the lines of comparing a doctor to a programmer. The doc needed a coder to do some debugging (whatever), and the programmer was horified by the code the doc had already done. Following this conversation (paraphrasing here): Coder: well, you're not a programmer. Doc: Yes, but it's easy. I've read books and know how to do it. Coder: Look at it this way; if I watch all seasons of ER and take a scalpel, surely I can perform a (something)-tomy. Doc: What are you talking about? Medicine is very complicated. And basically the doc didn't want to understand that, intresicly, programming was complicated as well (extra karma to the one who find this post, here or wherever else).

    I think most programmer needs to get that sometimes they are not good programmer, and do something about it. The great programmers, in that sense, should understand that all programmers are not as good as they are, and do something about it (and in their systems).

    And if you can, change the education system. I've seen enough prof use bad code as example (i.e. with buffer overflows in it or empty catches)... they are the ones who could do something fast.

  • Theo (unregistered)

    WTF was this entry?

    I'm not there to read stuff like that. For that I go to "serious" forums. This is simply not the place.

    Although it kinda made sense. Or not.

  • Kemp (unregistered) in reply to Josh
    Josh:
    Agile makes a tradeoff that allows productionalization and iteration at frequent intervals

    Any literature that includes works like "productionalization" immediately turns me away, no matter what the subject matter is. Marketting speak is for things that can't sell on their own merits.

  • Rhett (unregistered)

    I agree programming is hard and all that, but I think the number one probem is that software is EXPENSIVE. When you absolutely positively need the software to work, you shell out the cash and then it works. You think that guidance system in that ICBM is going to crash? Bet your ass that it wont. Now you think that scheduling system custom built by Assenture will crash? Damn right, because everyone's motivation was to grab as much cash from the project as possible.

    You say you need 10 people 2 years to finish the project? OK you get 4 people for 6 months. You want 5 QA engineers? OK you get 1, but he's not an engineer, he's some kid we hired to test.

    Software is expensive, and costs grow exponentially with complexity. And companies want to shell out the absolute minimum they can possibly get away with. And even if you are lucky, you get what you pay for.

  • blah blah blah name goes here (unregistered) in reply to Matthew
    Matthew:
    Alex, I forgive you for all of the insipid nonsense posts you've made in the past. You just completely redeemed yourself. I <3 you.
    You "<3" him? You shove an ice cream cone in his face? Or are those supposed to be your butt cheeks? Inquiring minds want to know.
  • kiggle (unregistered)

    What Agile advocates are claiming that anything that isn't an agile process will not be successful?

    The fact that a large number of successful non-agile projects exist says nothing other than that it isn't the only way.

    The argument is also being made that whenever an agile project fails, folks claim because it wasn't agile enough. That's a pretty heavy claim, and really can't be made accurate without giving specific agile advocates or "true scotsman"-ing 'Agile Advocate'.

    I always understood agile to be about not overestimating your ability to plan/design ahead, and as a result making what you do know as certain as you can as soon as you can, and limiting the cost of change by making the components loosely coupled and tested in full. This isn't practical in some languages and for some domains, but in those that it is, it seems to just come down to good software engineering.

    .. and of course, obsessive testing doesn't mean you don't have to give some thought to your code. I don't think any sane Agile advocate would advocate writing tests intelligently, then acting as a test-passing monkey. Code still gets thought and algorithms are still considered just as much, but there is the added benefit of well-factored code for clarity and a safety-net of tests.

    (Obviously, I've lost my train of thought. :-P Back to work for me.)

  • Richard C Haven (unregistered)

    No Clever Code

    Even if it works, everyone (even the original author) has to be that clever every time they try to understand it.

    Clever is for art. A piece of art does not change once it's been finished. Good software is comprehendible because, at the very least, someone will have to replace it one day.

    Simple works. Obvious works.

  • kiggle (unregistered) in reply to Poltras

    RE: Education..

    I think professors should use code that illustrates what they want to teach, but students of software engineering should be required to do projects in a scope that will require them to understand the difference between project code/academic code/demonstration code and production code. Then again, the concepts, idioms, and requirements for production code change across languages and companies, and since most classes are focused on teaching the concepts and not the minor technical details that will bite one in the rear in the Real World, teaching in simple/high-level languages where the pitfalls are mostly conceptual is probably a good idea until a hard-core software engineering class pops up in the curriculum.

  • Lee (unregistered)

    As far as I remember, no Pharaoh ever blundered in halfway through a project, changing his mind about the shape, location and colour of his pyramid.

    If they did, maybe the analogy would make sense.

  • (cs) in reply to JamesKilton
    JamesKilton:
    "no up-front design". Scary how many people think that Agile teams jump into a project with absolutely no idea of what they are doing. Here's how agile projects start out with what I've experienced:
    • Customer wants a product. Customer has a pretty good idea of what, but maybe not a lot of details
    • Agile team gets with customer and drills customer on what has to happen first, what the customer wants to see right off the bat.
    • A list of "stories" are created from this meeting, the functionality that is believed to be finishable within 4-6 weeks.
    • Agile team then gets to work, first prototyping functionality that may be new or unknown, and when such knowledge is gained, begins working on the app.
    • 4-6 weeks later there's a first "release" to the customer, who then is free to recommend changes, and approve the next batch of work. Next batches of work are expected to be every 2-3 weeks.
    • 2-3 week iterations continue until project is complete.

    So I hope I've cleared up / explained a few things about true agile development processes. Such posts as this come across to me as extremely uninformed, but I realize why people are thinking this, and it's unfortunate. So please, when someone starts bashing on the "failure" of Agile, remember what I've written here and assume that these "failures" are actually Agile practices by word of mouth only.

    Yep, you've cleared some things up. But I want to make sure I understand what you are saying. "customer wants a product... has a good idea of what" So customer provides some requirments.?

    "list of 'stories' are created" You design some stuff?

    "Team gets to work" (prototype then code) So you Implement some stuff? I assume part of the process of implmenetation is verification.

    "2-3 weeks iterations continue" I assume this includes maintenence of what was already written?

    Ok so how does this differ from the Waterfall method?

  • Theo (unregistered) in reply to Lee
    Lee:
    As far as I remember, no Pharaoh ever blundered in halfway through a project, changing his mind about the shape, location and colour of his pyramid.

    If they did, maybe the analogy would make sense.

    No, but sometimes they died though.

  • (cs) in reply to Rhett
    Rhett:
    I agree programming is hard and all that, but I think the number one probem is that software is EXPENSIVE. When you absolutely positively need the software to work, you shell out the cash and then it works. You think that guidance system in that ICBM is going to crash? Bet your ass that it wont. Now you think that scheduling system custom built by Assenture will crash? Damn right, because everyone's motivation was to grab as much cash from the project as possible.

    You say you need 10 people 2 years to finish the project? OK you get 4 people for 6 months. You want 5 QA engineers? OK you get 1, but he's not an engineer, he's some kid we hired to test.

    Software is expensive, and costs grow exponentially with complexity. And companies want to shell out the absolute minimum they can possibly get away with. And even if you are lucky, you get what you pay for.

    Be careful what you say... All of the Open Source Zealots seem to think software is cheap and should be given away for free.

  • Rhett (unregistered) in reply to Lee

    Actually he did. Look up "bent pyramid" which I suppose represents the current state of software development. I suppose this means in 500 years we will be able to program proper pyramids.

  • Doofus (unregistered)

    Most "developers" are self hating incompetent IDIOTS! (sorry most developers). They are "selected" on these traits because they are easier to control as a horde of spineless, gutless, selfhating pussies to do whatever the organization demands of them. They don't think of themselves as such. Neither does the career burger flipper at the local cow meat joint having been at it for the last 20 years.

    The more I work with corporate developers, the more I despise them. No amount of fad methodologies will help these sad pathetic figures. Like sad pathetic fat people, they are preyed upon by snake oil salesmen whose business it is to drive the "technical fad cycle" every half decade or so.

    If these people were doing actual work like the roadworkers or building engineers are doing (to some extent) they would be FIRED immediately because the products they build are hazordous and absolutely shoddy. But no one understands the IT/Computing "industry" so a lot of jackass posers get to strut around because they can put together a shitty piece of code.

    For every good developer out there, there are a thousand absolutely idiotic drones out there "building the future" right now.

  • (cs) in reply to Rhett
    Rhett:
    I agree programming is hard and all that, but I think the number one probem is that software is EXPENSIVE.
    It's actually pretty cheap, much cheaper than doing the same thing in hardware. But that lack of substance makes it hard to quantify the cost - so there's no concept of "as cheap as it'll go", and nothing to stop costs going any lower, except for expert insistence... and I'm sure we can all recount how well that works.
  • (cs) in reply to chrismcb
    chrismcb:
    Be careful what you say... All of the Open Source Zealots seem to think software is cheap and should be given away for free.
    I know it's flamebait... but as a fully paid up Free Software Zealot* the argument is not that software is cheap (although it is) but that retaining an artificial monopoly on duplicating it, once it exists, is not a reasonable way to make a living. That doesn't say anything about being paid (and frankly people should be paid damned well) for writing it in the first place, or for maintaining it over time.

    It's also pretty arguable that the "$500 buys you all the handholding and bugfixes you can bully us into doing" idea of off-the-shelf, proprietary software has reduced the perceived value of what programmers do by rather more than the "you've got the source, you can pay anyone you like to do the customisation you need" approach of free software. It isn't the least bit ironic, but it might well be true, that free software may end up costing a bit more in total, in the same way as hand-tailored suits cost more than Dress4Less. That's because the point of free software (and the reason I'm so keen on it) is the preservation of freedom, not the reduction of cost to 0 - when freedom is preserved, everybody benefits, even if specific things get a little harder.

    • Of course, "Open Source" is an inherently compromised term, so "Open Source Zealot" is necessarily an oxymoron ;)
  • Jon W (unregistered)

    Maybe the not-so-good people should try to find something they're good at to be doing, instead?

    Anyway, Agile solves one problem, and solves it well: it significantly reduces the cost of changing your mind. After having built large systems that took years to build, only to wake up and realize that the business now needed something totally different from when the process was started, I've found that thinking Agile helps a lot.

    • Make sure stakeholders know what's going on.
    • Make end users see the system during development and have a say.
    • Test each thing you build, as you build it.

    What's wrong with that?

  • (cs) in reply to Richard C Haven
    Richard C Haven:
    No Clever Code

    Even if it works, everyone (even the original author) has to be that clever every time they try to understand it.

    Clever is for art. A piece of art does not change once it's been finished. Good software is comprehendible because, at the very least, someone will have to replace it one day.

    Simple works. Obvious works.

    I believe it was Kernighan who said that debugging code is much, much harder than writing it, and therefore if you've written code as cleverly as you possibly can, you are by definition not clever enough to make it work properly.

  • (cs) in reply to Rhett
    Rhett:
    Actually he did. Look up "bent pyramid" which I suppose represents the current state of software development. I suppose this means in 500 years we will be able to program proper pyramids.
    So does this mean that Agile works best as a pyramid scheme? *ducks & runs*
  • Ryan H (unregistered)
  • (cs)

    I don't think you CAN have 1 method of development.

    But the method i like most is requirement gathering by prototyping. which basically means i construct the gui of the program with some functionality with duct tape and glue and a few strings tied in for good measure.

    This gives the client a good feel for what i think he wants. Then we basically joust a few days/weeks on what should be changed or added, again by rapidly putting the changes in the prototype, in the most fastest way i can manage.

    Then when the client is happy with how the prototype functions, i get out my drawing app and start writing some diagrams and doing some documentation on how the app should be built. And mostly because of the prototype i've got some good idea's on how to do that.

    The only really really bad thing about this way is that i also have to convince the client that the program he has been seeing is a complete wreck and wouldn't work in production. (which can be extremely hard) The other bad point is that it might take a bit more time then other ways of getting requirements, but the accuracy of the requirements is better i think.

    Also while a bit futile i try to talk about future idea's with the client, to identify parts of the app that need to be built flexible for future changes.

  • Simon (unregistered) in reply to Steve

    Have you read Extreme Programming Explained Second Edition? That's a perfect example of "constant refactoring" used on the process itself. We, in an Agile team, are also constantly refactoring our practices.

    I do agree with one of the comments above. Agile needs good developers. Those projects that failed even with Agile wouldn't do any better with any other methodology.

  • (cs) in reply to Jon W
    Jon W:
    Anyway, Agile solves one problem, and solves it well: it significantly reduces the cost of changing your mind. After having built large systems that took years to build, only to wake up and realize that the business now needed something totally different from when the process was started, I've found that thinking Agile helps a lot.
    • Make sure stakeholders know what's going on.
    • Make end users see the system during development and have a say.
    • Test each thing you build, as you build it.

    What's wrong with that?

    Reading what you wrote, it occurs to me that the core point of agile methodologies is "the prototyping process is actually a pretty good way of developing software, and management are going to confuse prototypes with final systems anyway, so you might as well make sure your prototypes are built robustly enough to deploy". Put that way, it's just common sense - I guess the problem comes when people see the "and this is how we ensure our prototypes are robust" bit and think it's the why, rather than just the how; then agile methods get capitalised, dogmatised, and rapidly devolve into a cargo cult.
  • Jeff (unregistered)

    People use analogies to distract and confuse, not to clarify. This pyramid is no exception.

  • SImon Rumble (unregistered) in reply to JamesKilton
    JamesKilton:
    You can take bits and pieces of the agile methodology and develop your own version. So these large companies pick only one, or two parts of agile (like the most often mis-understood "no-documentation" or "no up-front design") parts and then say "We're Agile!" when in fact they're no better than not having a methodology at all.

    Wot that man said! I've worked in loads of places that claimed to be agile. In fact I just turned a job down where they claimed to be agile ("we do two week sprints" was how they claimed to be agile). You can't pick and choose -- it's all mutually-supporting stuff, so you cut corners here while picking up the problems caused by cutting that corner there.

    I'd love to work in a place that did proper agile. Haven't seen it yet!

  • swain (unregistered)

    Agile is the biggest scam developers have pulled on management in a long time. Developers hate sitting down and thinking about what they want to build, they just want to sling code. Agile lets them do this. If you are building small green-field projects, agile is harmless, but for any enterprise-class projects, you absolutely need to plan before you code.

    The second biggest scam developers have pulled on management is XP. "Hey, let's fire all the testers and program managers and just hire devs - but we'll need twice as many since we have to work in pairs".

  • serge-nn (unregistered) in reply to brazzy

    Pair programming really reduces mistakes made by bad programmers - with the price of a good programmer slowed down, getting bored and frustrated. Back in USSR, mid-80s, when the PCs were a deficit and were priced higher than cars (an XT with a monochrome CGA, if you know what I mean), I had to do pair programming, and it was a great experience -- because my colleague and me had compatible minds and worked in the same pace. Anyway, once each of us got his own machine, we'd discuss things often, but do most of the work separately, which about doubled the productivity. Later, when I helped other (slow) people to fix stuff, looking over their shoulders, I was furious I can't just grab the keyboard and do it myself. So still, it's all about the quality of people, not methodologies.

  • Jax (unregistered)

    Never understand why we have to be pro or anti. IMO some of Agile is great, too much of it is shit.

  • Wow (unregistered)

    Wow. I am speechless. Agile processes: Toyota, Dell, Google.

  • (cs) in reply to Poltras
    Poltras:
    gwenhwyfaer:
    JamesKilton:
    The problem with our industry, as I see it, is that anyone can program.

    No, the problem is that programming is really fucking hard; and if you look at those people who are acknowledged as the best programers, they're generally the ones who acknowledge that, are all too aware of their own inadequacy for the task, and do whatever they can to mitigate that. What great programmers don't do is go around complaining that everyone else isn't good enough...

    I think I saw something on this forum about it, along the lines of comparing a doctor to a programmer. The doc needed a coder to do some debugging (whatever), and the programmer was horified by the code the doc had already done. Following this conversation (paraphrasing here): Coder: well, you're not a programmer. Doc: Yes, but it's easy. I've read books and know how to do it. Coder: Look at it this way; if I watch all seasons of ER and take a scalpel, surely I can perform a (something)-tomy. Doc: What are you talking about? Medicine is very complicated. And basically the doc didn't want to understand that, intresicly, programming was complicated as well (extra karma to the one who find this post, here or wherever else).

    I think most programmer needs to get that sometimes they are not good programmer, and do something about it. The great programmers, in that sense, should understand that all programmers are not as good as they are, and do something about it (and in their systems).

    And if you can, change the education system. I've seen enough prof use bad code as example (i.e. with buffer overflows in it or empty catches)... they are the ones who could do something fast.

    I believe this is the article you're referring to: "Trust me, I'm a Doctor" - http://worsethanfailure.com/Articles/Trust_Me,_I_0x27_m_A_Doctor.aspx

  • Tim Yen (unregistered)

    "We need to focus on improving the skills of the less-than-good in our industry."

    I reckon we need to get better tools that don't allow the less than skilled to write bad code.

    The great leverages for me are bigger and better libraries and better refactoring tools. Why the heck isn't there a code beautifier in every coding environment? Why isn't there an FXcop in every environment?

  • Spastic Weasel (unregistered)

    Actually, the Step Pyramid of Djoser was built in a manner similar to Gallanthotep's pyramid. Here's a link to show that I'm not completely talking out of my ass

    http://ccat.sas.upenn.edu/arth/zoser/20.gif

  • Angel (unregistered)

    I never even heard of Agile.

    We were taught 'XP' in university, as a compulsory 2nd year module. Along with the microcode and assembler module, it was one of the ones everyone said was a waste of time.

    I found the pair programming exercises interesting, although probably not for the reasons intended. It generally ended up with me writing code and my lab partner asking questions about my code (such as "Doesn't the comment have to be on the same line as the code?", and "What's a filehandle?"). I'm not sure, but I believe having to formulate answers to those questions made me think more closely about the simple things, and helped break a few bad habits. I'd like to think, too, that my partner actually learned something more than the cookbook-coding that our previous exercises had required.

    Then, a couple of years later, I'd mostly forgotten about XP. But then I walked in on a friend who was writing some pretty hairy perl, asked if he wanted some stew (I'd overestimated on the ingredients as usual). I glanced down at his screen and pointed at some code, "You can't use a typeglob as a hash key, can you?" 3 hours and a dozen ex-bugs later, we're both sitting in front of the big screen, passing the keyboard back and forth while the other person eats, asking questions about the code and catching each other's typos. It wasn't until the module was finished that I realised we were doing most of the stuff I'd learned in the XP classes.

    While I don't know that any particular methodology is "good" or "bad", I'm convinced now that those particular techniques proved useful for us.

  • (cs)

    I program by debugging: an empty file does not do what I want, so I start hacking. Sooner or later I have a prototype. If that prototype is extensible and elegant without being soft code (// just in case the value of True changes...), its good, otherwise refactor. After refactoring (even if it takes 40 prototypes), all that's left is polish and upkeep.

    As for the "professionals" who are too stupid to be allowed to sit in front of production code, there is a simple way to weed them out (its NIH, but...). Make an IDE that looks for obvious flaws and reports them to a BOFH. If a certain quota is reached, the BOFH replaces them with a small shell script ;)

  • Anonymous (unregistered)

    This is going to seem a bit childish, but I am going to stop reading WTF because of this article.

    Straw man, anyone?

    It's just sad to me that this site should be used for preaching. I've been here for almost 2 years but it's becoming increasingly clear to me that you're a complete idiot, Alex.

  • Jason Uithol (unregistered) in reply to Liberator
    Liberator:
    We all know that human capacity for handling complexity is limited. But to enthuse great programmers, you need to free them from being forced to do dumb things. Such as building things that are obviously useless, and bureaucracy getting in the way of productivity. XP helps a lot with that, and even helps to bring flow to not-so-good programmers as well.

    Apart from that, the pyramid story does not make sense. Neither as a historical anecdote, nor as an analogy. Imagine the whole world laughing at all those unfinished pyramids of long-dead Pharaohs...

    Pyramids were built with large number of slaves. Name one software project that had that many people working on it (That wasn't an operating system)

    Agile == Very unpyramid levels of labour funding.

  • Alexander Fairley (unregistered)

    I'm agnostic on agility. I do believe in using dynamic languages, but I abstain from crusades.

    However, you absolutely could build a pyramid by layering slabs onto an old pyramid. It's called a miter cut:

    http://en.wikipedia.org/wiki/Miter_joint

    Of course, the pyramid won't look right except for every iteration congruent to 0 mod 4(or 3 if you build a proper simplex). Not that that means you should base plans for major engineering projects off of slides presented by people making references to Highlights magazine and waving their hands around a great deal...

  • Larry Reid (unregistered)

    The method describe for building pyramids the "agile" way is exactly how the Maya and other Meso American peoples built their pyramids. So this particular argument against agile methodologies falls over like a stack of cards.

  • Rod (unregistered)

    In a word, facile.

    For this, and other simplistic analysis, stay tuned. Set up the negative case for agile, and leave us with the assumption that waterfall is good. Nobody I want to listen to would suggest that just badging your project 'agile' is all you need to do. Of course it's never that simple.

    I bet you fundamentally miss the point of why bigarsed waterfall projects are doomed. C'mon guess. It's because you don't know they're working till you're almost done.

    And about good programmers? You will never find one that doesn't test their ideas early, and continuously as they go. Waterfall is like typing the whole thing in, then trying to retrofit the fixes after the fact. Ooops fundamental design flaw. Too bad.

  • None (unregistered) in reply to buggy
    buggy:
    By the very definition of the word "good," most people are average, below average, or just plain suck.

    By the very definition of the word "average," most[1] people are average, below average, or just plain suck. And that remains true no matter how high the bar is raised.

    [1]Assuming most means "more than 50%."

    Obviously, that is not guarenteed to be the case. First, you assume that there is only one measure of developers. I claim, but will not support here, that there are multiple measures that could be used. And people will rate differently on each.

    But assuming you have a perfect metric for measuring development ability, you still aren't guarenteed to have a distribution centered on that mean. (In fact, if I cared, Attwood has an article showing that there are two, possibly three gaussian distributions of developers).

    In practice, you find that far more then 50% of developers fall below average. But that isn't, as claimed, nessecary from the definition. More than half could just as easily be above average if the distribution was mirrored.

    But now I'm just being pendantic.

  • None (unregistered) in reply to Rod

    Really this article has two points:

    1. Building pyrimids in an iterative manner is not a great method.
    2. The biggest problem facing the software industry is stupid people.

    Suggesting its Agile or Waterfall (or Cowboy) is a false choice.

  • slamb (unregistered) in reply to Angel
    Angel:
    Then, a couple of years later, I'd mostly forgotten about XP. But then I walked in on a friend who was writing some pretty hairy perl, asked if he wanted some stew (I'd overestimated on the ingredients as usual). I glanced down at his screen and pointed at some code, "You can't use a typeglob as a hash key, can you?" 3 hours and a dozen ex-bugs later, we're both sitting in front of the big screen, passing the keyboard back and forth while the other person eats, asking questions about the code and catching each other's typos. It wasn't until the module was finished that I realised we were doing most of the stuff I'd learned in the XP classes.

    While I don't know that any particular methodology is "good" or "bad", I'm convinced now that those particular techniques proved useful for us.

    That's a good demonstration that "Agile/XP" methods can be used by themselves. Both advocates and critics say otherwise, and they're both wrong. I assert the following:

    • pair programming is orthogonal.

    • "no detailed requirements" requires a customer representative (or proxy) and "no upfront design", but the converse is not true.

    • "no upfront design" requires aggressive refactoring, but the converse is not true.

    • aggressive refactoring requires unit testing, but the converse is not true.

    Besides that, the Agile/XP propoganda item that most grates on me is "100% unit test coverage and no bug fixes without a new unit test". I don't know how to achieve that extreme in entire classes of systems (e.g., kernels) or bugs (e.g., race conditions). There's nothing on the web about it, and Agile people blog their every thought. Given their silence, they clearly either have never written a non-trivial system or haven't done it in this way. I can't stand "silver bullets" that haven't been tried on werewolves, and I can't stand hypocrites, so either way this claim's no good.

  • (cs) in reply to Steve
    Steve:
    JamesKilton:
    So these large companies pick only one, or two parts of agile (like the most often mis-understood "no-documentation" or "no up-front design") parts and then say "We're Agile!" when in fact they're no better than not having a methodology at all.

    These are the companies that fail with Agile. Proper Agile takes a complete mental 180 of the entire development team for it to work, and 99% of all the "failed Agile stories" are about teams that do NOT take the leap.

    If iterative development is the best way to create or improve something, why is the process exempt from the set of somethings? Why can't "iterative development" and "constant refactoring" be used on the process itself? Basically, agile must be taken as faith, and any who fail just didn't have enough faith. I'm not sure if that's an argument that agile is bunk, an excuse to doom all who fail at agile, or both.

    It took me a second to figure out what you meant by this, but once I understood it, I think it is the single most insightful thing I've ever read about methodological zealotry. It doesn't even matter what side of the fence you're on.

  • (cs) in reply to chrismcb

    [i]Be careful what you say... All of the Open Source Zealots seem to think software is cheap and should be given away for free.[i]

    Note that FOSS developers exchange software for other software. The intermediate form of money isn't used as often. Code is currency.

  • Glyph (unregistered)

    This article was really disappointing.

    One of the things that I really like about this site is that it tries to focus on the really obviously bad, broken, stupid things about the ways people write software.

    There are lots of other sites that make more nuanced arguments about the pros and cons of specific methodologies, languages, tools, techniques, schools, certifications, and so on, but "WTF" could always be relied upon for plain old terrible code and terrible management. It provided a baseline from which we could all agree - okay, that's terrible, let's not ever get that ridiculous. That baseline is important for the more nuanced discussions, so we can all tell when it gets ridiculous.

    Agile methodologies are not "worse than failure". Don't take this as a defense of "agile" - the term is so vague it defies definition, let alone defense. But there are many valid - even good - ideas and techniques under its rubric. Even if there weren't, it isn't something which is obviously bad, something which marks someone as clearly incompetent, in the same way that so many of the other brain-damaged ideas described here do.

    To lump "Agile" in here gives the site an unpleasantly political tone. What's next? An opinion piece on Java vs. .NET? IE vs. Firefox? Emacs vs. VI?

    I have my own opinions on these, and many other, issues, but to mention a technology here alongside all the horror stories isn't just a critique, it's a damnation. Now that you've done that with "Agile", it makes me suspicious of the next article. Is that program that calculates a sum by OCRing a dialog box really that stupid? Now I'll have to look twice.

  • Will Sargent (unregistered)

    I quite like the software tester who can well, justify his existence to an agile team:

    "They are shocked that even though all their automated unit tests pass, the program fails basic, manual scenario tests. So I work with them some of the time teaching them how to think more like a tester, and to do manual functional testing in conjunction with their TDD work, as well as my own testing. I usually see a marked improvement in the code they deliver once they start doing more testing on their own work, testing in contexts other than the source code."

    http://www.qthreads.com/interviews/testing/agile_teams_miss_out_by_having_a_narrow_focus_on_testing.html

    http://www.informit.com/articles/article.asp?p=405513&rl=1

  • Anony Moose (unregistered) in reply to Doofus
    Doofus:
    Most "developers" are self hating incompetent IDIOTS! (sorry most developers). They are "selected" on these traits because they are easier to control as a horde of spineless, gutless, selfhating pussies to do whatever the organization demands of them. They don't think of themselves as such. Neither does the career burger flipper at the local cow meat joint having been at it for the last 20 years.

    The more I work with corporate developers, the more I despise them. No amount of fad methodologies will help these sad pathetic figures. Like sad pathetic fat people, they are preyed upon by snake oil salesmen whose business it is to drive the "technical fad cycle" every half decade or so.

    If these people were doing actual work like the roadworkers or building engineers are doing (to some extent) they would be FIRED immediately because the products they build are hazordous and absolutely shoddy. But no one understands the IT/Computing "industry" so a lot of jackass posers get to strut around because they can put together a shitty piece of code.

    For every good developer out there, there are a thousand absolutely idiotic drones out there "building the future" right now.

    <aol> Bra. Vo. </aol>
  • (cs)

    First of all, it should be noted that it is [b]perfectly possible[b] to build a threedimensional pyramid the Gallanthotep way. All you have to do is to add two coherent faces every time you expand the pyramid. The assumption that is is not possible to build a pyramid sideways is easily disproved with a handfull of lego bricks.

    Then, for obvious reasons, agile methods is good for custom made software only. Building boxed software requires a completely different approach. Like any other tool, you have to know how and when to use it.

    Agile methods probably rely more than other methods on having good people, but then, I'm not really sure that average or bad programmers are of any help at all, no matter which methodology is used. For obvious reasons, if you have a a) large team and b) an elaborate process, chances are that a) of those many people, some are good and b) there is a lot of rather useless work to occupy the bad coders, so the good ones can get the job done.

Leave a comment on “The Great Pyramid of Agile”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article