The Great Pyramid of Agile

« Return to Article
  • Zemyla 2007-05-24 16:02
    Wait, people are still using "Goofus" and "Gallant" for analogies?

    Most people got over Highlights many years ago.
  • Matthew 2007-05-24 16:12
    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.
  • ParkinT 2007-05-24 16:15
    Wow. I am speechless.
  • Saarus 2007-05-24 16:16
    I believe the analogy between software design and development and pyramid construction to be foolish.

    Software development can sometimes be liked to a pyramid, given the correct circumstances, but by and large, software development is evolutionary rather than creationary. Even in a waterfall, SDLC, whatever, compromises are inevitably made to the original design, to satisfy changing or unforseen requirements. I submit this compromising is more easily accomplished with software than with brick and mortar.
  • null reference 2007-05-24 16:23
    Amen!
  • eatenbyagrue 2007-05-24 16:24
    I hope I'm not the only one to say so, but.. you're wrong. Agile does work, in most business cases, better than waterfall design. Granted I wouldn't want to manage rocket launch software dev that way, but rockets only launch one way. Business processes change constantly.
  • Lucas Goodwin 2007-05-24 16:24
    Although I do use TDD (Sort of and only because we don't have a testing department so this reduced my testing efforts dramatically), I'm not a true agilista (I don't follow nor believe in the whole XP, SCRUMM, yada yada crap) but I do see a lot of good things in the processes they recommend.

    That being said, what Agile is really aiming at is Lean Manufacturing techniques targetted at Programming. A laudable goal I personally think. Having been a Mechanical Engineer, a Machinist, and a Software Developer (Among other things), I've found the following analogy for Software Development to be fitting.

    A Software Developer is both Mechanical Engineer and Machinist. He designs the product and builds it at the same time. I haven't found any real holes in this analogy so I'll go with it to justify Lean Programming.

    TMP (Toyota Manufacturing Process AKA Lean Manufacturing) works. REALLY works. Decades of evidence to prove it. If lean manufacturing encompasses the total process of development and production of a physical product/plant operation, isn't it reasonable that the same techniques can address the issues we have with building good software that successfully meets the demands of the customer on budget and on time? After all, the TMP is more focused at adapting to change rapidly, communication, and scheduling. These are universal issues that apply to both the real and virtual world.
  • Saarus 2007-05-24 16:24
    Saarus:
    I believe the analogy between software design and development and pyramid construction to be foolish.

    Software development can sometimes be liked to a pyramid, given the correct circumstances, but by and large, software development is evolutionary rather than creationary. Even in a waterfall, SDLC, whatever, compromises are inevitably made to the original design, to satisfy changing or unforseen requirements. I submit this compromising is more easily accomplished with software than with brick and mortar.

    Aargh... meant to conclude by saying that, because the analogy does not hold for all cases, it is fallacious.

    I think most developers look at methodologies as a frame of reference. Sometimes, agile methods are well-suited to a task. Sometimes, more traditional approaches work best. It all depends on the people you have, your client, the scope of the project, and other factors too numerous to mention. Although I agree with the point that our standards for acceptable skill are too low, I disagree with the fact that agile methods are somehow "wrong" just because there are people on that side of the fence who think that traditional methods are "wrong".

    Extremes bother me. Be flexible, but don't be so flexible that you can't be inflexible.

    I guess that makes sense to me.
  • Gabriel C. 2007-05-24 16:26
    Is kind of ironic that XP, the poster child for agile methodologies is very strict and fragile: if you can't follow ALL the practices ALL the time, you're in danger (the circle of snakes will break loose)... the fact that is marketed as a religion doesn't help.
    Isn't also ironic that the poster project for the poster methodology was cancelled and almost never used?
    Worse Than Failure indeed!

    But don't listen to me, I got feed up with eXtreme Propaganda when the eXtremos raided OTUG mailing list many years ago
  • Name 2007-05-24 16:28
    I don't think it's a coincidence that most of the code on this site comes from monolithic, bloated, waterfall-driven development. Has there ever been a unit testing WTF?
  • zip 2007-05-24 16:30
    Article:
    As for the cases of failure, the answer is overwhelmingly, “of course it didn’t work; the project didn’t have enough good people.”

    Good people can build good software no matter what methodology they use. We don’t need a weight-loss pill for thin people; we need to solve the real problem behind failure in our industry.


    A-freaking-men.
  • JimmyB 2007-05-24 16:30
    Any assumption that Agile methodologies are simply a change in process are wildly inaccurate and misleading. Approaching agile or XP in this manner are almost guaranteed failure. Just read Kent Beck's Extreme Programming Explained or Craig Larman's Agile and Iterative Development to see the difference.

    Iterative development has been around much longer than the "Agile" moniker. It's nothing new. But gathered together, Agile is a set of values, principles, and practices that shape a new approach on the same problem. This problem being that computers can't be programmed in the language of business folk.

    Speaking from personal experience, all waterfall projects I was involved with were a major PITA, and all agile projects I was involved with were actually fun. No set of practices guarantee success, but it's only with Agile values and practices that I've seen teams (rather than just individuals) drastically improve.
  • Josh 2007-05-24 16:31
    I'm not a huge fan of Agile either, but this seems like a broad misinterpretation of the core methodology. Agile makes a tradeoff that allows productionalization and iteration at frequent intervals, but at the cost of taking more overall time to complete. This can be appropriate for projects that have uncertain and shifting requirements and/or need frequent checkpoints (and a lot of service-based contracts fit this profile).

    There is no free lunch--it makes some aspects better at the cost of others.

    Consider that the major problems of software projects are still cancellation, over budget, and failing to meet business objectives. Agile can help with all three, and nowhere does the methodology state that you can get away with not planning.
  • livid 2007-05-24 16:38
    Name:
    I don't think it's a coincidence that most of the code on this site comes from monolithic, bloated, waterfall-driven development. Has there ever been a unit testing WTF?


    One unit test WTF, coming right up:

    public final void testCriticalFunctionality()
    
    {
    try {
    ... Bunch of stuff to exercise code ...
    // Commented out on XX-XX-XX by XXX to fix test failure
    // assertTrue("Some important assert", condition);
    }
    catch(Throwable t)
    {
    // Don't let anything fail this test!
    }
    }

  • JamesKilton 2007-05-24 16:39
    So what do you suggest Alex? Waterfall with it's enormous up-front design stage and complete reliance that nothing changes? No methodology, where every developer just does what they want to and *hope* that the final system is functional?

    Articles like this really, really hurt those of us who do and succeed with Agile methodologies and the adoption of *true* Agile. I'll explain.

    Agile is suffering from fad-dom. Larger companies, sick of the constant failings of Waterfall or sick of not knowing what or when software will even be developed, are flocking to try out this "Agile" stuff that "promises" massive results quickly. These same large companies are then shocked when they realize what Agile actually entails: pair programming, test driven development, short iterations, lots of customer communication, lots of developer communication, etc. But, this is Agile we're talking about! 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.

    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.

    Alex, one just cannot compare software development to anything in the physical world for the main reason of the fact that software requirements change over time. It always happens, always has happened and always will happen. This simple fact is *the* reason that Waterfall fails so badly. So if you want to compare software to pyramid building, then the iterative pyramid building is the way to go because when the pharaoh suddenly wants a tower, there's much less that needs to change than if you built the full base of the original pyramid. And given that, if the pharaoh never changes his mind, you *also* end up with the full pyramid. Who cares if it has parts where it doesn't look right, that's a whole part of software.

    To clarify some parts of Agile:

    "No documentation". Obvious hit with managers, as this implies much less project management time spent by the team. What this idea is saying is that the code documents itself both with good programming style AND most importantly with the tests written to prove correctness of the code. This Agile part does NOT excuse writing of usage documentation and manuals.

    "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.
  • Undefined Reference 2007-05-24 16:39
    Before people get hung up on the whole Agile bashing and defending, realize that the most important point in this essay is the lack of standards.

    A more productive discussion is how it would be possible to create standards. And enforce them.

    In what way could we collectively improve the collective abilities in the field. It seems that some sort of certification or licensing is needed. That people need to prove their ability before they can do work professionally.

    But that idea seems contrary to many of the people who started into this field. They still have memories of when they were exploring new ideas. But now, to establish reliability, the field must evolve standards.

    It will happen. Regardless of pressure from those stuck in the past, the industry needs a way to ensure that the work is done by those capable of doing that work. It will happen , but it would be better if it could happen with the help of the people who went before.

    I read sentiments like Alex's post all the time. But he is in a position where he has the power that can help bring change. Between Alex, Jeff, Joel and whoever else joins the band, there is enough to start a serious movement to instill standards in this industry.

    A chance to go beyond noticing or complaining about the lack of skilled workers in the field. A chance to grow the industry.

    Or we can leave it at a simple post, all talk, that is destined to be forgotten once it falls off the main page.

    I focus on Alex because he has a loud voice that can reach a large number of people. And yet all the readers here can do your part.

    Anyone who complains without taking any action is wasting everyone's time. Do not stand for incompetence any longer.
  • cavemanf16 2007-05-24 16:40
    Lucas Goodwin:
    Although I do use TDD (Sort of and only because we don't have a testing department so this reduced my testing efforts dramatically), I'm not a true agilista (I don't follow nor believe in the whole XP, SCRUMM, yada yada crap) but I do see a lot of good things in the processes they recommend.

    That being said, what Agile is really aiming at is Lean Manufacturing techniques targetted at Programming. A laudable goal I personally think. Having been a Mechanical Engineer, a Machinist, and a Software Developer (Among other things), I've found the following analogy for Software Development to be fitting.

    A Software Developer is both Mechanical Engineer and Machinist. He designs the product and builds it at the same time. I haven't found any real holes in this analogy so I'll go with it to justify Lean Programming.

    TMP (Toyota Manufacturing Process AKA Lean Manufacturing) works. REALLY works. Decades of evidence to prove it. If lean manufacturing encompasses the total process of development and production of a physical product/plant operation, isn't it reasonable that the same techniques can address the issues we have with building good software that successfully meets the demands of the customer on budget and on time? After all, the TMP is more focused at adapting to change rapidly, communication, and scheduling. These are universal issues that apply to both the real and virtual world.


    Great points about what the real underlying goals of Agile programming are, and I agree with your analogy of a software developer being both Mechanical Engineer and Machinist - to a point. Guys like me (Computer Engineering Technology B.S., a decent amount of experience in "business" processes, and a Six Sigma Greenbelt) should be acting, partially, as the mechanical engineer in your equation, with the software engineer as the highly technical, service oriented "machinist" building what I've designed. Although I can also see the need for a secondary, more IT-related Architect doing the real engineering of the software instead of me before it gets handed off to a programmer.

    I like to think of it this way: There is exactly one Golden Gate Bridge, and it took a long time to build it, and the best bridge painters, engineers, and construction workers get to maintain it. But there are A LOT of bridges all over the USA. Are they all built as superbly as the Golden Gate Bridge? No way! But they work. Sometimes they're over-engineered, sometimes they're constructed poorly, etc. What matters is that they simply work. And they work because you have government inspectors checking up on their specs and how well they meet them before, during, and after they are built. Do we have such luxuries with software in big business? Hell no! So we end up with a lot of WTF work products in software development.

    Any guesses from readers on this site on how long it will be until software development is more highly scrutinized than merely Sarbanes-Oxley controls?
  • SuperousOxide 2007-05-24 16:41
    Just shows that any analogy will fail if you take it far enough. I'm not saying Agile development is a good thing or a bad thing, most likely it works for some cases and doesn't work for others there's no silver bullet, but pointing out a hole in an analogy doesn't mean Agile is inherently flawed.
  • Anon 2007-05-24 16:42
    Saarus:
    I believe the analogy between software design and development and pyramid construction to be foolish.


    Of course it's foolish, software isn't written by teams of slaves mercilessly beaten daily by their masters for little or no reward, right? Right?
  • Saarus 2007-05-24 16:46
    Anon:
    Saarus:
    I believe the analogy between software design and development and pyramid construction to be foolish.


    Of course it's foolish, software isn't written by teams of slaves mercilessly beaten daily by their masters for little or no reward, right? Right?


    It isn't?
  • rmr 2007-05-24 16:48
    Let the religious methodology wars begin. . .
  • anne 2007-05-24 16:50
    God bless you. When I saw "Agile", I thought "Oh, no, it's going to be a post on fad software methodologies."

    And then you made the analogy with diets. Brilliant. I couldn't agree more.

    To those of you defending agile, I'm sure when it's implemented by a strong team, it works -- but nothing will change the fact that you need good developers to write good code, and it's still hard.

    Thank you!!!
  • Liberator 2007-05-24 16:51
    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...
  • superted 2007-05-24 16:53
    It'd be nice if there was a way to know that this was an opinion essay, not a normal WTF. Could you tag these differently, like the Error'd? Or maybe tag the normal WTF. I enjoy the WTFs, but I would prefer to skip these.
  • RadiantMatrix 2007-05-24 16:58
    One huge problem I have with articles like this -- and, by extension, with a lot of Agile zealots -- is the idea that the Agile method fixes quality problems. It doesn't, and that's not the reason to use it.

    I've used Agile for a while now (and have used RUP and XP, and Waterfall that claimed to be everything from RUP to Agile). From where I sit, the real strength of Agile is that it allows good developers to get a lot done.

    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.

    Like everything else, a team must choose the right tool for the job -- if you have bad developers, and you can't get rid of them, don't try to use Agile. You'll fail.

    Or, worse, you'll "succeed" in creating horrible (but up-to-spec) software.
  • mnature 2007-05-24 16:59
    Anon:
    Saarus:
    I believe the analogy between software design and development and pyramid construction to be foolish.


    Of course it's foolish, software isn't written by teams of slaves mercilessly beaten daily by their masters for little or no reward, right? Right?


    So say we all . . .
  • Steve 2007-05-24 17:01
    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.
  • SomeCoder 2007-05-24 17:03
    Liberator:
    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.


    In my experience, that's really not true. I find myself having to go through a lot more bureaucracy with Agile than I had to before.

    That might just be how my company implemented the Agile process but that's been my experience with it.

    Overall, Agile doesn't seem all that much worse or better from what I was doing before. Yes, there's more bureaucracy but the overall result seems to be the same to me.
  • JamesKilton 2007-05-24 17:04
    The problem with our industry, as I see it, is that anyone can program. If you have a computer, and an internet connection, you can download a compiler / interpreter, check out a few tutorials, and you're off. There's no personal accreditation authority for Computer Science professionals, just departments and college degree programs, but even then I don't think it would help much. There is a very low barrier of entry into our job, and until that bar is raised higher, we will have problems with crappy code and a reason for this site.
  • gwenhwyfaer 2007-05-24 17:07
    JamesKilton:
    Articles like this really, really hurt those of us who do and succeed with Agile methodologies and the adoption of *true* Agile.


    Why? If it's that good, surely its merits alone are enough to fend off articles like this one?

    This article simply contends that agile methodologies are neither necessary nor sufficient to produce good software. What is your argument with that?

    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.


    That's an ouroboros of an argument - teams will fail unless they adopt Agile completely, and the demonstration that they haven't is their failure.

    But what worries me much more than a couple of specific arguments (and the fact that you spent over half your post evangelising Agile) is that your post reeks of the fervour of the recent convert. I know a bit about this; I grew up amongst evangelical Christians, and this kind of argument was really common there - all criticism was personal, none was engaged with on any intellectual level, and the core assumption was that the critic just needs One More Explanation (usually one packed with just those kind of circular statements and logic avoidance tactics) and they'd suddenly see what they'd failed to understand before. It must be said, there's a lot of personal pride involved - everyone making such a pitch secretly hopes to be that one person who puts it well enough that it cannot be resisted, the person who finally "scores" one for their team.

    It's sad when one sees such thoughtless, counterproductive pseudo-advocacy applied to something as important as human spirituality. But to see it promoting a project management discipline...? That's... ridiculous. And about as welcome in the workplace as religious fundamentalism, too.
  • Single Male 2007-05-24 17:07
    anne:
    To those of you defending agile, I'm sure when it's implemented by a strong team, it works -- but nothing will change the fact that you need good developers to write good code, and it's still hard.


    More to the point...what about waterfall *prevents* your project from ending up on this web site if you have incompetent co-workers?

    Seems to me that a lot of XP and Agile and similar consultant fodder are just about making sure that all the code you write is hardened against various kinds of preventable screwups.

    Once you a) acknowledge that some people are going to write screwed up code, b) take steps to detect and control screwups, c) make sure the user stays "in the room" so that people stay on topic and don't get lost in technical rat-holes, and d) make sure people actually produce something useful more than once every two years, you're going to avoid the top four traps that failed projects tend to land in.

    After that, it really doesn't matter what crazy-ass scheme you use to develop the software (which is why you can get away with less of some things like advance planning or documentation), because someone is going to cry "WTF" and get things back on track.
  • GrandmasterB 2007-05-24 17:07
    Write clean code, document it, and test it well. Basic truisms of software development since the 60s. If you need to name your 'programming methology' then you're a tool.

  • GrandmasterB 2007-05-24 17:11
    JamesKilton:
    The problem with our industry, as I see it, is that anyone can program...There's no personal accreditation authority for Computer Science professionals


    The problem with that approach is that the best programmers tend to be anti-establishment and unconcerned with certifications and other meaningless trappings. Its the BAD programmers that rely on those things because they cant let their code speak for itself.
  • Robert 2007-05-24 17:12
    I think you better do some research on agile before writing about it. The agile manifest clearly states "people over processes". Pair programming helps develop people's skills and get them to know the project. And so on.

    On the pyramid example: it's just like saying "cars can not be built because pyramids don't have wheels either".

    And finally -- is this article the WTF or where is it? Did you plan to post that on April 1st?
  • Mark B 2007-05-24 17:12
    Ok while I do agree with Alex that bad programmers make bad code, which in turn makes bad software.
    I also think that agile while not with out flaw, does encourage programmers to adopt better practices or at the very least more standardised practices (in that if they have made a mistake then it would be a consitant one).
  • ferdd 2007-05-24 17:16
    I work for THE firm that teaches CMM/CMMI and both our COTS and custom dev teams are small. The waterfall approach can and does work well, but you need big money and sufficient staff. Face it, BDUF costs money to gather requirements and to document, and there will still be changes because it is impossible to gather all the requirements (most companies don't even know what their business processes are, let alone articulate them correctly, and even if/when they do, they will at some point realize they are insufficient/incomplete). Then you have to do all the other requirements which all cost a lot of manhours/money. Agile can work well with CMM, and almost has to if you have small teams and need to produce. Even Watts Humphrey, who developed PSP/TSP and CMM, recognizes that, even if he doesn't espouse Agile. These are his five reasons that projects fail:

    "
    Unrealistic Schedules
    You might think that pushing for an aggressive schedule would accelerate the work, but it actually delays it. When faced with an unrealistic schedule, engineering teams often behave irrationally. They race through the requirements, produce a superficial design and rush into coding. This mad scramble to build something - anything - results in a poor-quality product that has the wrong functions, is seriously defective and is late.

    Inappropriate Staffing
    The only way to complete an engineering project rapidly and efficiently is to assign an adequate number of people and then protect them from interruptions and distractions. This helps build the motivation and effective teamwork needed for quality results. When managers fail to provide timely, adequate and properly trained resources, their projects will generally fail.

    Changing Requirements During Development
    To start designing and building products, engineers must know what product to build. Unfortunately, management, marketing and even customers often don't know what they want. Worse, they think they know and then change their minds partway through the job. While the requirements (or objectives) normally change in the early phases of a job, there's a point beyond which changes will waste time and money and disrupt the work.

    Poor-Quality Work
    Consider the case of Greg, manager of a manufacturing software project that had to meet an accelerated delivery date set by his boss. Greg unmercifully pushed his engineers, who rushed through the design and coding and skipped all of the quality reviews and inspections. Testing found many defects, but Greg argued for delivering the software and fixing defects later. Greg met the deadline, but the system was a disaster. It was so unreliable that the software had to be fixed every time a change was made in the product or product mix. Excessive factory downtime and repairs cost the company over $1 million. When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn't work. There's a saying about software quality: "If it doesn't have to work, we can build it really fast."

    Believing in Magic
    Commercial off-the-shelf software, or COTS, is an attractive way to save development time and money. But COTS isn't a silver bullet. If not properly managed, it can be a disaster. A COTS product that works perfectly in demonstrations, for example, may crash when subjected to different hardware configurations, higher data rates or even data-entry errors. You must test the product thoroughly enough to expose previously untested conditions. If the program is troublesome when stress-tested, it will almost certainly be troublesome when used in production.
    - Watts S. Humphrey
    "

    So regardless of what methodology, or combination of methodologies are used, it comes down to whether or not you do your work correctly. You still need requirements, realistic schedules, proper staffing, adequate dev team and user testing, and knowledge of what the business processes really are. Adding the fluff that the users want that will be used 10% of the time can be added after it goes into production if the schedule is strict.

    FWIW, I happen to like Agile more than waterfall/CMM, if for no other reason than I want to do more than 7 lines of perfect code per day.
  • APH 2007-05-24 17:16
    Agile - moving quickly and lightly

    The fact is software, by its very nature, is in constant flux. It's just so *easy* to change, it almost can't be helped. In this regard, Agile is a good word. It has some good points, my favorite is this one: Test Early, Test Often

    I like that. It seems reasonable, doesn't it? Making tests as you go along? Wait, that means there would have to be *expectations*, and *requirements* at or near the time you start writing the code. That doesn't sound very Agile-like, does it? No, it isn't, and that's where Agile falls flat. You can't test when you don't have starting cases and ending cases (aka "Expected Behavior").

    I would reason that all methodologies have some useful nuggets in them. XP has peer work/review - it's hard to say that a second pair of eyes looking at your code is a bad thing. It makes you accountable, but at a cost.

    Just remember, There Is No Silver Bullet.
  • aaaaaaaa 2007-05-24 17:17

  • gwenhwyfaer 2007-05-24 17:22
    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...
  • wunar 2007-05-24 17:24
    Sweet article! Yet, I was kind of sure that I was reading CodingHorror when I read this post in my reader, so I'm not exactly certain that this is a plus for the DailyWTF (though, on the other hand, this is no DailyWTF anymore, so it's cool).
  • buggy 2007-05-24 17:29
    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%."
  • jefrainmx 2007-05-24 17:29
    So Agile just work for small project team, in which must of the cases have too much process bureaucracy don't worth it.
  • Geezer coder 2007-05-24 17:39
    Oh, gawd, the Agile bigots are at it again. In these discussions, we always seem to lose sight of three pieces of data:

    1) untold thousands of systems have been successfully built with so-called waterfall approaches

    2) few, if any of the major commercial software vendors with major, real world large scale systems uses an Agile approach, and they seem to find a way to get packages to market

    3) Kent Beck has spent more time promoting XP than he ever did actually developing systems, and the system which he touts as the success story is a minor system in an organization that is filled with other successful systems developed using other methods.

    Let's get real, kids. XP and the other agile approaches package together a set of practices which are undoubtedly good ideas, and I absolutely support, for example, storydriven development (can you say use case), test driven development (can you say tightly specified requirements, automated builds, frequent reviews, engaged users, etc. However, Agile projects are a minority in the world today, and they will continue to be a minority, because they only work for projects of a certain nature, with certain user/business commmunities, and with certain developers. Agile fan boiz always seem to conveniently forget the millions of lines of reliable code that have been produced outside of agile methodologies.

    I am of the belief that the best methodology is the one that works for the team that is using it. That tends to be team dependent, organization dependent, and customer dependent. Agile methods are often a good way, but you are simply being delusional to consider it to be the only way.

    To see this point, consider Agile from an evolutionary context. If Agile were truely the best and only way to produce quality code, then the companies and teams that use Agile methods should be able to consistently outproduce the companies and teams that don't. The world class software organizations, including those folks down the street in Redmond, would HAVE to turn to agile to be cmopetitive, and we would be speaking of Agile as we do of IDE's. That is, which one do you use, rather than do you use one.

    I have been hearing this argument since I ran a pilot team using XP in 2000. The developers loved it, the client hated it, the system worked, but our company went bankrupt anyway (not related to the choice of development methods).

    As Brooks said, before most of the Agile proponents were born, there is no silver bullet.

  • chad 2007-05-24 17:39
    Ahem:
    http://en.wikipedia.org/wiki/Straw_man
  • opensorcerer 2007-05-24 17:40
    I might buy into this analogy, if you were talking about building a pyramid on a former swamp that had been partially drained, in the middle of a continuous 7.5 earthquake. Because I don't know what kind of solidity your requirements and environment have, but that's approximately how mine are. Let's also throw in a request from the Pharaoh for a cubical tomb mid-project, because the market research says cubes are going places now and we can't afford to become #2.
  • mrprogguy 2007-05-24 17:40
    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 Mr. Kilton expressed himself badly. What he wanted to say was "...[just about] anyone is allowed to program."

    That's a bad thing.

    Like you said, this business is really difficult, and it isn't getting any easier. The drop in the current number of graduates in a programming curriculum demonstrates that students realize this. "Wow, it's just really, really hard to write computer software. I better go into the mortgage business," they say.

    Next thing you know, a lot of sub-prime lenders are going out of business. But I digress.

    When the number of available good people drops, businesses have to take whomever is left standing in the street, and those folks are generally not on par with the 1st or 2nd tiers. The problem is, people who can be good programmers already are; you can't take a bad programmer and build a good programmer because the bad programmer doesn't have the right instincts and intuitions from the get-go.

    Certification doesn't matter--when there are no more certified people to hire, the uncertified get hired. (Except for critical stuff like flight computers, nuclear-reactor control software, and rockets. We hope.)

  • ferdd 2007-05-24 17:42
    No, that's not what I wrote. I implied that it takes money to use BDUF up front and make it agreeable to the customer. Small teams usually don't get that kind of money, and rarely have all of the skills needed to do BDUF. If you can read between lines -- it's called inference, by the way -- the customer has to agree that BDUF -- a longer time to see results -- is worth *their* money.

    But since you can't spell and grammatics is completely out of your realm, I suppose I shouldn't be posting any rebuttals anyway.

    Captcha: sanitarium -- chode up yer butt
  • crusty old guy 2007-05-24 17:43
    In case anybody missed the 2006 conference on Waterfall software development, here is a link: http://www.waterfall2006.com/.

    I haven't heard anything about the 2007 conference yet, but I am sure that is because they aren't releasing the schedule until everything is ready.
  • NotManagementMaterial 2007-05-24 17:44
    I think those that get caught up in discussing the different successes in methodologies and why one should use one over the other has a bit too much time on their hands. I think that whatever methodology you use, if you have good people who actually do work instead of talking about methodologies - will breed a good product.

    Simple formula: less talk + more code = product success

    The simple approach is normally the best one.
  • ferdd 2007-05-24 17:45
    Sorry all, that chode was for jefrainmx

    captcha: burned by lack of quote button
  • Nick Radov 2007-05-24 17:48
    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.
  • brazzy 2007-05-24 17:56
    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 2007-05-24 17:59
    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 2007-05-24 18:03
    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 2007-05-24 18:21
    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 2007-05-24 18:39
    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 2007-05-24 18:40
    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 2007-05-24 18:47
    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 2007-05-24 18:54
    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 2007-05-24 18:54
    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 2007-05-24 19:09
    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.
  • chrismcb 2007-05-24 19:10
    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 2007-05-24 19:11
    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.
  • chrismcb 2007-05-24 19:14
    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 2007-05-24 19:15

    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 2007-05-24 19:15
    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.
  • gwenhwyfaer 2007-05-24 19:25
    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.
  • gwenhwyfaer 2007-05-24 19:42
    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 2007-05-24 19:45
    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?
  • gwenhwyfaer 2007-05-24 19:46
    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.
  • gwenhwyfaer 2007-05-24 19:49
    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 2007-05-24 19:54
  • stratos 2007-05-24 19:54
    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 2007-05-24 19:55
    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.
  • gwenhwyfaer 2007-05-24 19:57
    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 2007-05-24 20:06
    People use analogies to distract and confuse, not to clarify. This pyramid is no exception.
  • SImon Rumble 2007-05-24 20:32
    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 2007-05-24 20:35
    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 2007-05-24 20:46
    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 2007-05-24 20:49
    Never understand why we have to be pro or anti. IMO some of Agile is great, too much of it is shit.
  • Wow 2007-05-24 21:10
    Wow. I am speechless. Agile processes: Toyota, Dell, Google.
  • ObiWayneKenobi 2007-05-24 21:24
    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 2007-05-24 21:31
    "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 2007-05-24 21:42
    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 2007-05-24 21:44
    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.
  • Spacecoyote 2007-05-24 21:48
    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 2007-05-24 22:31
    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 2007-05-24 22:55
    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 2007-05-24 23:00
    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 2007-05-24 23:31
    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 2007-05-24 23:38
    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 2007-05-24 23:48
    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 2007-05-24 23:52
    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 2007-05-25 00:54
    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.
  • bif 2007-05-25 01:19
    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.
  • devdas 2007-05-25 01:19
    [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 2007-05-25 01:26
    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 2007-05-25 02:21
    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 2007-05-25 02:38
    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>
  • ammoQ 2007-05-25 02:38
    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.
  • Konrad 2007-05-25 02:41
    If you treat the methodology as infalable it is garanteed to fail.

    This is what put me of XP rather rapidly. Yes I agree that there is no magic bullet which will make IT cheap, easy and fast. If creating software was that simple we would have programs to write all our programs by now and actual programming would be a lost art.

    I for one favor a more moderate Agile approach. WHich has just enough documentation, a healthy set of Tests which test what can be automatically tested, and a minimisasion of components which can't be automatically tested.

    As a futher asside yes the analogy is fairly shaky, but hay it is an analogy, they all break if you push things far enough.

    captcha pirates (The flying spagetti monster was here)
  • Jan Hudec 2007-05-25 02:41
    One of agile development basic rules is refactor mercilessly. This means, that failures along the way have chance of being fixed up, while in waterfall model there's little room for changing things that turned out wrong.

    However it:

    1. Requires that the programmers recognize the failures.

    2. The manager actually allows them to refactor. Usually even if the programmers realize a failure, the manager only sees fixing it as lost time and will forbid doing it.
  • ammoQ 2007-05-25 02:42
    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.


    Nonsense. Open source is about freedom, not price.
  • pirannia 2007-05-25 02:44
    NotManagementMaterial:

    Simple formula: less talk + more code = product success


    You're so wrong here, on so many levels...
  • ammoQ 2007-05-25 02:47
    Jan Hudec:
    One of agile development basic rules is refactor mercilessly. This means, that failures along the way have chance of being fixed up, while in waterfall model there's little room for changing things that turned out wrong.

    However it:

    1. Requires that the programmers recognize the failures.

    2. The manager actually allows them to refactor. Usually even if the programmers realize a failure, the manager only sees fixing it as lost time and will forbid doing it.


    Refactoring does not necessarily mean that you fix failures. The original code might have been perfectly valid at the time it has been written, but because of continuous changes, it has reached a point where a alteration is necessary. For example, a method starts small, but as more and more details are added, it becomes too large and should be broken into smaller parts.
  • Stephan Schmidt 2007-05-25 02:48
    "Good people can build good software no matter what methodology they use."

    I don't think so. Good people can build good software no matter what methodology they use when they stick to it.

    The difference between CMMI and Scrum for example is, that there are hundreds of pages for CMMI which you have stick to and 5 rules for Scrum which you have stick to. Guess which methodology people can easier follow? Beside that, agile methodologists think that agile works fine together with CMMI and other "heavy" process models.

    And most agile methodologies (Scrum, Crystal, ...) don't say anything about how good people need to be (well non agile users most often only know XP or mean XP when they use the word agile and deduce from there that agile methodologies only work with good people).
  • Stephan Schmidt 2007-05-25 02:52
    "One of agile development basic rules is refactor mercilessly."

    This is not a basic agile rule, whereever you got that idea from. This is a XP rule, where XP is a methodology which formed the term agile but so far has been quite unsuccessfull because of the mixture of technology and managment practices. Most other agile methodolgies don't say anything about technology or development techniques like pair programming, unit testing or refactoring. This was a XP only, and a bad one, most agile practioneers think today.
  • anon 2007-05-25 03:03
    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.


    Bzzt, category mistake. There are somethings iterative development are good for creating. Those things are called "programs". Agile is not a "program".

    Even if you wanted to somehow "refactor" Agile, what sort of methodology would you use? Perhaps some kind of genetic algorithm? Why don't you "refactor" that, too? How would you choose to?

    It's turtles all the way down. Diagonalization makes turtles happy.

    Now, this doesn't mean there isn't room for variation. There are plenty of kinds of Agile programming. See http://en.wikipedia.org/wiki/Agile_Programming#Agile_methods
  • brazzy 2007-05-25 04:00
    Rhett:
    Software is expensive, and costs grow exponentially with complexity.

    See, that's exactly the point of formal development processes: they intend (and, to varying degrees acceed in) preventing costs to grow exponentially, or even quadratically with complexity, and thereby allow large and complex systems to be developed at all.

    I strongly suspect that everyone here who's scoffing at development methodologies and harping on how the real point is that other programmers aren't good enough has just never been involved in a really large and complex development project.

  • Nilsie 2007-05-25 04:16
    I prefere to fire the bad programmer.
  • Anonymous 2007-05-25 04:21
    serge-nn:
    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 know what they are, but not what you mean.

    "Monochrome" means single-coloured. CGA stands for Colour Graphics Adaptor. They're 2 different things. One for monochrome displays. One for colour displays (even though the number of colours is very limited -- 16?). How come you can mix these 2 things together as "monochrome CGA"?


    "Monochrome" can actually refer to 2 things at that time. 1) The MDA (Monochrom Display Adaptor) can only display text and in only 1 colour (amber/green/white, depending on the type of phosphor used on the monitor) besides black, but can highlight text using a brighter colour, underlining, blinking or a combination of these. 2) A successor called Hercules card is backwards compatible with MDA, and also has graphics modes (single-coloured, though), allowing high resolution graphs to be plotted.

    CGA, the alternative to monochrome, could display both text and graphics in a limited number of colours. It's resolution is lower, though. So, many offices opted for the MDA for better resolution, because the computer operation has to operate the machine for long hours. (Monochrome monitors are also cheaper.)
  • Jeremy 2007-05-25 04:33
    Single Male:

    Once you a) acknowledge that some people are going to write screwed up code, b) take steps to detect and control screwups, c) make sure the user stays "in the room" so that people stay on topic and don't get lost in technical rat-holes, and d) make sure people actually produce something useful more than once every two years, you're going to avoid the top four traps that failed projects tend to land in.

    After that, it really doesn't matter what crazy-ass scheme you use to develop the software (which is why you can get away with less of some things like advance planning or documentation), because someone is going to cry "WTF" and get things back on track.


    Slap a front and back cover on this and get it to O'Reilly.

    (Try not to let them post a sample chapter, though...)

  • SecretUser 2007-05-25 04:38
    There was a point made in that article that great programmers should realise they're great and help others. I used to work for a company that wanted a TRAINEE software developer. They offered full training. Their training was heres google off you go. Now obvioulsy I sucked at it and needless to say I dont work there any more.

    From my experience experienced programmers don't seem to be too interested in helping others become good at all. All they seem to be interested is making themselves look even better at the expense of their colleagues. Ok in my case it was a little bit extreme. But I've heard of similar cases from hundreds of people across the UK. I now work in IT support because of this as I've not managed to find a developer willing to invest time in training someone to be on their level.

    Apologies for a kind of sweeping comment I'm sure there are thousands of exceptions.

    Just wondered what other peoples experiences were
  • Nyuserre 2007-05-25 04:52
    Liberator:
    Imagine the whole world laughing at all those unfinished pyramids of long-dead Pharaohs...


    Imagine Menkaure's son Shepseskaf completing his father's pyramid after his death.

    Or perhaps Neferirkare: "But he died before the complex was completed. The work on the pyramid was stopped, and the funerary complex quickly finished, using mudbrick and tree instead of stone." (But good old Nyuserre later refactored it for his dear ol' dad.)

    Not sure what my point is.
  • woof 2007-05-25 05:16
    Agile methods are like any other tool. If you use it incorrectly you're gonna get hurt! Agile methods DOES NOT mean that you throw planning out the window. It does not mean you cobble together a system. It just a different way of building the system, a way that (wait for it) responds well to change and often allows the user to give feedback earlier and more often than with traditional methods - avoiding the classic "Thats what I wanted, but not what I need" scenario (look up "requirements analysis).

    Agile methods work well - if used responsibly and not as an excuse to produce poorly documented, poorly designed and poorly built software systems.
  • MadMike 2007-05-25 05:21
    I'm currently working in the IT-Department of a insurance company. Amongst others, we use mainframes to run our applications.

    I just recently overheard my colleagues talking about technology fads. First they started âbout AI and how management thought it would make IT people obsolete. To which I silently agreed. Then they talked about the java-courses they had so many years ago and how management OO-Programming would change the way IT would work. They dismissed it as a fad too. I remained silent.

    OO and Java were both hyped strongly, but it still have some merits. It makes programming easier for some projects (especially larger ones). It doesn't deserve to be dissed the same as AI. Still for some people it's just the same type of fad.

    I thought to talk to them and explain them the merits of OO. The problem is, its almost impossible to explain when the other person has never tried it.
    My guess with agile development is, that it supports some very good technologies (like SVN and Unit-testing) and that you can't really judge it, if you never tried it.

    But then educating other people about being a better programmer? Who are you kidding? Are you going to be the arrogant prick running around telling other people how to do their job?
    And even if you are right, why should they begin to improve? I know so many programmers who take pride that they don't pick up a book to learn and who don't want learn anything outside their job or a outside a paid course.

    The only thing you can do is to lead by example. Try to be a good programmer and try to improve. If you do a good job, people who are interested in becoming better themselves will come and ask what you different than others.
  • Wigy 2007-05-25 05:41
    There is a huge difference between the attitude of people who worked in a successful agile project and those who were just nicked for some money by a consultant firm. Now comes my experience, sorry consultants:

    Agile does not work for average people. It just helps good people cooperate with each other without the average mass behind them. Good developers not always have perfect people-skills. Sometimes they have a big ego, so it's more comfortable for them to work among less-skilled developers.

    Did you try to get Picasso and Monet to work on the same painting? This is the only thing these methodologies solve: to get the focus back on rational arguments instead of fighting with each other. This way you do not need 10 average developers per a good one to provide a kingdom for them, which helps efficiency in the end.
  • jmo21 2007-05-25 06:01
    James,
    i absolutely agree, this is the biggest problem in IT.

    it can derail any methodology, adoption of new technology, or even a "normal, everyday" project for a company


    JamesKilton:
    The problem with our industry, as I see it, is that anyone can program. If you have a computer, and an internet connection, you can download a compiler / interpreter, check out a few tutorials, and you're off. There's no personal accreditation authority for Computer Science professionals, just departments and college degree programs, but even then I don't think it would help much. There is a very low barrier of entry into our job, and until that bar is raised higher, we will have problems with crappy code and a reason for this site.
  • BAReFOOt 2007-05-25 06:24
    Well Alex,

    "eat less" still cannot work. The problem is *what* you eat.
    It depends on the amount of energy the food gives you over time and how full your stomach feels.
    If this amount is less than the energy you actually need, you'll get thinner. if not you will be fat soon.
    Now "normal" food is really bad because it consists of very simple (short) carbohydrates like kinds of sugar, starch, white flour. They get splitted into sugar very quickly, go into the blood very quickly, and because too much sugar is toxic for your blood (see diabetes) your body uses insulin to move the sugar very quickly out of the blood and into your fat cells.
    So the longer the carbohydrates, the longer it takes to digest the same amount of energy.

    So it's NOT the fat has to be avoided. It's the short carbohydrates, and most of the time the sugar and white flour (which btw is a completely dead conserve).

    For the fat there is another simple rule. The lower the viscosity, the more unsaturated it is, the more healthy it is, because that's the fat that you *need* to digest certain vitamines or to lose weight. (That's why margarine - whlie made from unsaturated oil - is very saturated, and therefore bad. Else it woil not be solid!)

    Now all this would make you thinner... but still very sick.
    The reason for this again is that you need to maximise the variation of your food to maximise your health.
    And i mean all variations of proteins, vitamines, minerals, trace elements, fibers, ... te deliver all kinds of building blocks to repair your body and grow some muscles and immune system cells.

    And last but not least never but *never* forget those 3 rules:
    1. If you think of it as i diet (eg something that you will stop with at some time), you will also stop staying thing at that time... plus the additional bonus of getting even fatter because you body learned to use the energy better.
    2. You food has to TASTE well. If it's not, you WILL stop with it and it WONT work. Period! (So don't even try to lie to yourself. Because you know when you do it!)
    3. Every change needs some time to get used to it. You're oeor the hill when you realize that you start missing when you don't do it. Just stay focused until this happens and you will succeed.

    Good luck! :D
  • brazzy 2007-05-25 06:41
    Wigy:
    Agile does not work for average people. It just helps good people cooperate with each other without the average mass behind them. Good developers not always have perfect people-skills. Sometimes they have a big ego, so it's more comfortable for them to work among less-skilled developers.

    Did you try to get Picasso and Monet to work on the same painting? This is the only thing these methodologies solve: to get the focus back on rational arguments instead of fighting with each other. This way you do not need 10 average developers per a good one to provide a kingdom for them, which helps efficiency in the end.

    Quite the opposite.

    This kind of arrgance (People who think of themselves as comparable to Picasso and everyone else as "less skilled") is exactly what ruins projects, and the methodology to solve it is not "agile", it's not hiring such people for any project they can't complete on their own. In a project of any real size, egomaniacs hurt far more than they help, no matter how "good" they technically are (which is usually not nearly as good as they think). The solution is to dump them and find people who are good AND have people skills so they can help you average programmers be productive rather than use them to stroke their ego.
  • Anonymous pyramid builder 2007-05-25 06:47
    Sure, attack the metaphor, and display your ignorance while doing so.
    First and foremost, it’s probably not even possible to build an Egyptian-style pyramid sideways. A pyramid is a three-dimensional shape (the diagram/analogy assumes it’s a triangle), and adding to a face would make it ruin its nice, square base.

    Somebody didn't play with enough building blocks as a child - that building scheme extends trivially into three dimensions.
    Secondly, a foundation must be laid prior to construction. I would imagine that constantly changing and adding to the building’s foundation in the middle of construction is a bad idea. I doubt such a building could last a few seasons, let alone a few millennia.

    No foundations required if you build it on solid bedrock.
    Thirdly, the intricate tunnels, rooms, and corridors within a pyramid would be pretty hard to plan out if the size of the building constantly changed. It’d probably end up looking pretty ridiculous once the pyramid was finally complete.

    Well, they're not that complex in most pyramids. The pharaoh's tomb is basically in the middle, and the tunnels are straight, sufficiently so that people believe that they follow sight-lines from the pharaoh to particular stars*.

    * I do not believe this.
  • dkf 2007-05-25 06:57
    BAReFOOt:
    "eat less" still cannot work. The problem is *what* you eat.
    It depends on the amount of energy the food gives you over time and how full your stomach feels.
    The amount of weight you have depends on the balance of calorie intake versus calorie output (i.e. how active you are). If your intake exceeds your output, you put on weight. If you eat less than you "burn", you lose weight. It is that simple.

    Other things (rate of absorption, etc.) may affect other important aspects of your health, but your weight is almost entirely down to calorific balance.
  • Fracarret 2007-05-25 06:58
    (maybe) random thoughts after reading the post:
    - Agile is not meant for the "less than good". Processes and tools, were invented so that average people would have some reliable way of dealing with a vast quantity of small, hard to remember, not always applicable, details. Relying instead on people interaction seems to be a strategy where you expect people to be capable to directly deal those details. Most can't "by the very definition of the word "good""

    - Because it is not meant for the average does not mean it is useless for the good. Getting rid of "for dummies" processes and tools makes sense for people that are actually slowed by those things. Of course the end result has to be the same, and accountably so (or at least the customer must believe it is the same)

    - Because it is meant for the good will maybe boost up the spirits of the average subjected to it. Maybe this will make them more efficient. If so, why not think that the same boost could be achieved by having processes that are less "do it exactly like this, you stupid !" and more "in case you don't remember what to do in this case, try this" ?

    - Because the Agilists are making a great business selling us dummies their credo, does not make them bad. They exploit the natural resources around. Thanks Alex for pointing this out: as with miracle diets, the evil is within us, not within the product we childishly by to feel better and avoid looking for the real causes of our discomfort.
  • Grrr 2007-05-25 07:26
    Anonymous:
    serge-nn:
    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 know what they are, but not what you mean.

    "Monochrome" means single-coloured. CGA stands for Colour Graphics Adaptor. They're 2 different things. One for monochrome displays. One for colour displays (even though the number of colours is very limited -- 16?). How come you can mix these 2 things together as "monochrome CGA"?


    First off, it was 4 colors not 16 (EGA had 16).

    Secondly, what the OT refers to, is probably just that - a computer with CGA card attached to a monochrome monitor.
    It was pretty standard and not even for Soviet PC clones (like Iskra (or "spark" in English)), but also for various other PC clones like Olivetti PC XT I used to sit at when I was around 5 years old.
  • jtwine 2007-05-25 07:50
    JamesKilton:
    The problem with our industry, as I see it, is that anyone can program. If you have a computer, and an internet connection, you can download a compiler / interpreter, check out a few tutorials, and you're off. There's no personal accreditation authority for Computer Science professionals, just departments and college degree programs, but even then I don't think it would help much. There is a very low barrier of entry into our job, and until that bar is raised higher, we will have problems with crappy code and a reason for this site.


    Actually, I do not think that the barrier of entry is too low, but rather the barrier of exit (so to speak), is too high. It is understood that a fresh-out-of-school programmer may do dumb things, make stupid mistakes, and likely not be the best person to architect a system.

    However, it is not understood that just because someone has been around the block a few times, that it should be assumed that they are doing quality work. I have seen lots of "principal developers" doing dumb/stupid things that I stopped doing 3 years out of school. There tends to be very little controls in place to get these kinds of developers out of the company.

    I think that all developers should have their code go through some kind of peer-review. XP and other Agile processes mandate this, so that is at least a step in the right direction, IMHO.
  • sir_flexalot 2007-05-25 07:50
    Rather than try to educate the uneducatable, wouldn't it be easier to just not hire incompetent coders in the first place?
  • _js_ 2007-05-25 08:07
    I like how Alex equates thin people with good programmers, and says fat people plain suck at programming.

    Because it's true.
  • JarFil 2007-05-25 08:14
    Undefined Reference:
    create standards. And enforce them. [...] a way to ensure that the work is done by those capable of doing that work. [...] lack of skilled workers in the field.


    Quite a misconception this one, that standards will make up for the lack of skilled workers. Well, they aren't.

    Truth is, there is far more work to do than skilled people are there ever going to be. This is not floor mopping, where 90% are skilled enough; we're talking about CS, where we try to make software precisely to solve problems that no average person is able to solve easily.

    Far gone are the times when software did the same a person would, just did it faster. Now, we want software to work both faster and better than the user would. We want software the average end-user will never completely understand, and more and more often the average programmer will neither (think API, libraries, copy&paste).

    So, by definition of CS itself and what we expect from it, either you also employ the not-so-skilled, the average and under-average, and you plan for integrating them into your production processes... or you just end up with a gross and ever-increasing lack of skilled labor.
  • dkf 2007-05-25 08:15
    Grrr:
    First off, it was 4 colors not 16 (EGA had 16).
    There were several different selectable sets of four colors with CGA, though all were ugly. Let's face it, PCs of that era had terrible graphical displays, though their text handling was pretty good if you had MDA or EGA.
  • Damo 2007-05-25 08:25
    Alex:
    you have to know what to build before you can start building it


    Wait!!! There are business that know this shit?? Where? WHO?!?!! Sounds like Bizaro land to me.

    Agile was born *because* business do not know what they want to build and the *always* change their mind during the construction.

    You trying telling your architect that you want to increase the ground floor space when the roof is going on.

    Actually, I fuckin' hate software-property building analogies.
  • Damo 2007-05-25 08:37
    chrismcb:
    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?


    eh, the iterations? the bit where the client gets to see regular drops? frequent client communication? low cost of change?

    http://www.digitalfocus.com/_includes/pop_agile_vs_waterfall.html


  • Eponymous 2007-05-25 09:14
    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%."


    I'm sorry... I can't let this inaccuracy go by. You've used the definition of "median" where you said "average," which means the arithmetic mean. The median is the value that 50% of your samples fall below. The average is the sum of all values divided by the number of samples.

    Here's an example: I have 5 people whose IQs are 100, 100, 100, 100, and 10. The average IQ is 82. In this case, 80% of my people are above-average! But the median would be 100, which is clearly more representative of the data...

    I'd say I'm just being pedantic, and of course part of me is doing just that -- but I truly believe that this kind of miscommunication is exactly what leads to inaccurate requirements, coding errors, and the like. All the Agile in the world will never overcome inaccurate communication...
  • Dave Nicolette 2007-05-25 09:16
    Reading the comments here gives me a feeling of nostalgia.

    Many people disparage "agile" without ever having experienced an agile project; their arguments are based on assumptions and, in some cases, the logical fallacy known as the Strawman (e.g., "Since agile is marketed as a religion, blah blah blah").

    Many others respond to this by accusing the first group of promoting "waterfall" methods; their arguments are based on the logical fallacy known as the False Dilemma (e.g., most of those who have doubts about agile methods are interested in effective alternatives to the waterfall, they just aren't convinced that agile works).

    These arguments are so far out of date, they make me feel young again. Thanks for that!
  • poochner 2007-05-25 09:38
    JarFil:


    Truth is, there is far more work to do than skilled people are there ever going to be. This is not floor mopping, where 90% are skilled enough; we're talking about CS, where we try to make software precisely to solve problems that no average person is able to solve easily.

    ...

    So, by definition of CS itself and what we expect from it, either you also employ the not-so-skilled, the average and under-average, and you plan for integrating them into your production processes... or you just end up with a gross and ever-increasing lack of skilled labor.

    Don't confuse CS with IT, please. They're not the same thing at all. There's not much of a market for CS people outside academia (Google is one place). They certainly don't program for a living.

    "A real computer scientist never programs in anything less portable than a number 2 pencil."
  • database guy 2007-05-25 09:48
    Turns out that pyramids in Egypt are built upon older ones, at least for the oldest one. Don't you watch the Discovery channel?
  • Thuktun 2007-05-25 09:48
    Actually, what this indicates is that analogies generally suck at giving you insight into an issue and may actually misinform.
  • NeoMojo 2007-05-25 10:09
    <pedantic_rant>
    The word is METHOD. Sure, you can redefine the meaning of methodology from "the study of methods" to mean "method", but WHAT IS THE POINT? Yeah, maybe it's been put into dictionaries now, or it's in wikipedia or some other crap, it's still a pointless word. If I were to be cliche, I'd say some about TRWTF...
    </pedantic_rant>
  • JD Powell 2007-05-25 10:26
    Saarus:
    Aargh... meant to conclude by saying that, because the analogy does not hold for all cases, it is fallacious.


    I mean to start and conclude by saying this analogy is fallacious because pyramids are not built that way.

    In the agile case, you are layering ontop of a finished pyramid. However, a pyramid like the Great Pyramids at Cheops is a step pyramid of square blocks covered - when finshed - by regular prisms called casing stones. These stones are meant to be polished smooth and whitewashed (painted brilliant white with a simple led paint.)

    Each 'finished' smaller pyramid would have to be built on top of these smooth layers. They could not be built at all for reasonable effort even given a Pharaoh's significant labor pool. If built, these larger pyramids would be fragile rinds on the outside of a building.

    And to top it off, like the casing stones, the next conquerer to pass through the project would just rip off the nice outer layers to make their fancy buildings. This was done by Napoleon and the Moors to the Great Pyramids.

    Come to think of it, this sounds a lot like real-world development. Maybe it is a good model after all. Projects reusing half-assed APIs and tools not built with reuse in mind. Pillaging previous projects to jump start existing ones. Bad Software Engineering as a method of tacky veiner piled upon tacky veiner piled upon something that actually worked for someone, somewhere.

    CAPTCHA: ewwwww, how I feel about this Agile Metaphor.
  • Dietmar 2007-05-25 10:30
    Nobody every said they should use the waterfall model.
    There is more out there than waterfall and agile development.

    I think what alex wants to make a point is that you need to know the outline, the outcome of the whole project to start with so you can have sombody, preferable good, to make the framework for the project.
    After you build that base you can use the agile methods as well as others to create the business logic in whatever suits best to the given situation


  • Randy 2007-05-25 10:33
    This article is full of fail.

    Flawed analogy.

    Author demonstrates little comprehension of subject matter.

    Article fails at being helpful to newer programmers.

    Get some perspective. This nonesense is the epitome of WTF.

  • Alonzo Meatman 2007-05-25 10:39
    Just because you can't do everything 100% Agile doesn't mean that you should chuck the whole thing out the window. I believe that the best way to develop is sort of a compromise between Agile and Waterfall-like methodologies.

    For example, you do need to have an overall plan for what you are doing. However, once you have an overall plan, there's no reason that you can't factor that plan out into many stages, with each stage producing a working deliverable.

    Really, what it all comes down to is a tradeoff between forethought and refactoring. The more forethought you put into a project, the less refactoring you have to do after every product release. Obviously, too much forethought, and you'll never actually code anything. Not enough forethought, and you'll have to spend ages refactoring your codebase every time you make a release.

    Agile and Waterfall represent two ends of a vast spectrum, with many shades of gray in between. It's up to the developer to decide how much forethought to put into a given project. There's no one-size-fits-all solution, but as any programmer knows, such things do not exist in the world of software development.
  • PhreakBert 2007-05-25 10:46
    Zemyla:
    Wait, people are still using "Goofus" and "Gallant" for analogies?

    Most people got over Highlights many years ago.


    This way I don't have to go to the dentist any more.
  • real_aardvark 2007-05-25 11:38
    brazzy:
    RadiantMatrix:

    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

    Proof, please, if you would be so kind. As a gedankenexperiment:

    * What happens when (not if) you pair two really bad programmers?
    * What if BDUF (GIHTA, or, God, I Hate That Acronym) were to incorporate extensive unit tests? Shock, horror!
    * What if your Whig Theory of Programming is as unfounded as its equivalent in History, and constant refactoring means that crappy code merely gets churned into a different wodge of crappy code, now with hidden extra bugs?

    And as for the gentleman who suggested that XP is great because it produces a solid base for the less talented programmers who come along later to maintain it, may I recommend that he look up the 80/20 rule? Why should anyone assume that the original team is any better than the maintenance team?
  • Damo 2007-05-25 12:02
    Unfortunately, it's the only way to present it to businesses.
  • Damo 2007-05-25 12:03
    Damo:
    Unfortunately, it's the only way to present it to businesses.

    Bad analogies I mean...
  • Diana Larsen 2007-05-25 12:04
    "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?"

    When teams take any Agile method seriously, they inspect and adapt iteratively with frequent retrospectives, not just the code but all aspects of the project at hand. Through the experiements and actions they chose during the retrospective, they "constantly refactor" methods, process and teamwork. I have heard several of the Agile thought-leaders say some variation of, "If you aren't holding retrospectives at the end of every iteration, release, and project, you aren't 'doing' Agile." I agree. So the the answer to the question above is...iterative development and constant refactoring ARE used on the process itself.
  • Cydonia Mensae 2007-05-25 12:23
    First and foremost, it’s probably not even possible to build an Egyptian-style pyramid sideways. A pyramid is a three-dimensional shape (the diagram/analogy assumes it’s a triangle), and adding to a face would make it ruin its nice, square base.

    Somebody didn't play with enough building blocks as a child - that building scheme extends trivially into three dimensions.


    It gets better: the first recognizable Egyptian pyramid (the famous step-pyramid of Djoser in Saqqara) was in fact built this way, and in many ways is more analogous to the Agile development method than the more simplistic example given. The pyramid was not originally intended as a pyramid. It started life as a mastaba, a stone edifice with walls slanting slightly inward which terminated in a broad, flat top. Sort of a mesa. But the brilliant architect Imhotep (yes, *that* Imhotep) got the idea to make it more spectacular and began adding on to it. (This was not driven by a desire to achieve a pyramid even if the pharaoh died prematurely; in fact, Djoser's longevity contributed to the continual improvement of his mastaba.) He built it outwards on two faces, widening the original mastaba, and then built a second, smaller mastaba on top. Then he did this again a few more times until Djoser passed away and had to be interred in the thing. The design was very popular, and subsequent pharaohs also had such edifices constructed, with various architects adding their own innovations until eventually they settled on the clean lines we're accustomed to.

    Many other pyramids around the world were also built by building a small pyramid and then expanding it successively. In fact, this was the standard method for building pyramids in most Mesoamerican societies. Those pyramids were not usually intended as tombs for royalty (some were) but rather as temple complexes, and they were expanded progressively over a period of centuries.

    Secondly, a foundation must be laid prior to construction. I would imagine that constantly changing and adding to the building’s foundation in the middle of construction is a bad idea. I doubt such a building could last a few seasons, let alone a few millennia.

    No foundations required if you build it on solid bedrock.


    Yep. None of the Egyptian pyramids have or require foundations; they are built directly on bedrock.

    Thirdly, the intricate tunnels, rooms, and corridors within a pyramid would be pretty hard to plan out if the size of the building constantly changed. It’d probably end up looking pretty ridiculous once the pyramid was finally complete.

    Well, they're not that complex in most pyramids. The pharaoh's tomb is basically in the middle, and the tunnels are straight, sufficiently so that people believe that they follow sight-lines from the pharaoh to particular stars*.

    * I do not believe this.


    Actually, it's true -- some of the pyramids are lined up in this way, most notably the Great Pyramid of Khufu (aka Cheops). The Ancient Egyptians were very much aware of astronomy and attributed special significance to the rising and setting of certain stars, mainly for agricultural purposes. (It helped forecast the Nile's annual floods.) It also tied into their beliefs pertaining to the afterlife, where pharaohs were believed to join the sun-god on his Barque of Millions of Years. Aligning the passages correctly was intended to help the pharaoh's spirit navigate (the Egyptians had some very complex ideas about life after death).

    However, it is worth noting that the tunnel no longer points at its intended spot in the heavens, but towards another spot. Between the real motion of the stars and the precession of the Earth, the stars are not precisely where they were four thousand years ago.
  • NotManagementandProud 2007-05-25 12:31
    Except for his name. That appears to be right.
  • jmperso 2007-05-25 12:34
    To say (and I quote) that "Agile methodologies simply cannot work." is to have presumed that all those who believe that Agile does work, somehow are preaching that "Agile is right for everybody". "Cannot" is an extreme(ly) non-agile pre-presumption - a self fulfilling conclusion of a sense.

    As a firm Agile "believer" with success under the belt - I do not, and have never, thought that Agile is for everyone and certainly have never thought that everyone has to use Agile the same way. To presume such, is the antithesis of the definition of Agile itself - that is, to be non-agile.

    So, I guess you aren't a hypocrit - because you act (say) consistently with what you believe. But then again, you just don't KNOW what you are talking about when you use such exclusive presumptions.
  • Wolfger 2007-05-25 12:41
    The real WTF here is how you consider Atkins to be a "fad diet". It's a real diet that really works, and lazy people who can't be bothered to stick with the diet plan are the main reason for gaining the weight back. Heck, the only thing most people "know" about the Atkins diet is "you can eat all the meat you want". They hear that, the brain shuts off, and they don't learn the rest of what they need to know. I followed the diet and lost about 60 pounds, and kept it off until I left the diet. It's really that simple. Honest. And if I had a buck for each person who thought they knew what the diet was really like but didn't really have a clue, I'd have made some decent cash.
  • jmperso 2007-05-25 12:57
    Randy:
    This article is full of fail.

    Flawed analogy.

    Author demonstrates little comprehension of subject matter.

    Article fails at being helpful to newer programmers.

    Get some perspective. This nonesense is the epitome of WTF.



    Well put.
    Signed - (Author of 138739)
  • Best not to say 2007-05-25 13:07
    I was surprised to find an editorial here. But maybe we can salvage a real WTF from this mess by talking about a real example: I was hired to create a new software process at the Ford Motor Car Company. (Ford's lawyers my contact you to remove this post.) The process I was given to start with was a mess. So I fixed it. Having some back ground in agile processes I added some of the basic agile principles. I then gave it to several projects to use. Ford measured and found that my process was saving 27% of their costs. That is their measurement by an independent team, not mine.

    So what did they do? They decided to use it everywhere. Great, except that those agile concepts are just not acceptable. So they changed it to be non-agile same as the process they were replacing. Will it save them 27%? Of course not. Will there be a press release stating that Ford threw a 27% savings into the toilet? Of course not. The trade magazines will report that Ford rolled out an agile process and it didn't save them a dime. WTF!

    Agile processes can and do work with ordinary (not so good) programmers. It does not work with undisciplined programmers who can't be bothered with following a process. Most of the projects I have seen that use a traditional process actually use no process at all at the programmer level. Agile processes introduce the concept that even programmers must follow a process. This causes many programmers to fight them because being unaccountable is easier.

    If you actually read the paper that introduced the venerable waterfall process you might be surprised to find the author predicting that it will never work because it doesn't take into account changing requirements. Agile processes are not a fad. They have been around as long an any other development process you care to name. The difference is that it is now acceptable to use them. Prior to the Extreme Programming publicity explosion it was considered a bad thing to only use as much process as you actually needed. It was considered inappropriate to tell precious programmers how to work efficiently. It was also considered a bad thing to think about software development as something different from building a pyramid.

    Some people are fanatical about Agile Methods because we have started a revolution. It isn't about this method or that method; it is about realizing that software development is only a few decades old and we are just now finding out that software is different from everything else we have centuries of experience building. We don't know yet how to build software effectively; some people see that as condemnation, but you can choose to see it as an opportunity instead.
  • Fregas 2007-05-25 13:08
    Alex,

    I've been a steady reader and contributor for years now. Pretty much everything needs to be said has already been said, and i agree that the pyramid is kind of a stupid analogy. But its clear that you don't understand agile. Its been hyped as yet another silver bullet the same way OOP has and RDBMS, but when it gets down to it, its work. But you should really understand the methodologies and the movement seperate from all the BS Hype surrounding it before you criticize.

    Guys, look at this way:

    RDBMS's aren't perfect, but they are better than what went before (flat files, for example)
    OOP isn't perfect, but its better than what we had before (procedural)
    Agile isn't perfect, but its better than what we had before (waterfall)
  • NotanEnglishMajor 2007-05-25 13:30
    _js_:
    I like how Alex equates thin people with good programmers, and says fat people plain suck at programming.

    Because it's true.


    Yes of course, and all generalizations are false!
  • sol 2007-05-25 13:35
    What is this plan you speak of oO
  • itsMeAgain 2007-05-25 13:43
    livid:
    Name:
    I don't think it's a coincidence that most of the code on this site comes from monolithic, bloated, waterfall-driven development. Has there ever been a unit testing WTF?


    One unit test WTF, coming right up:

    public final void testCriticalFunctionality()
    
    {
    try {
    ... Bunch of stuff to exercise code ...
    // Commented out on XX-XX-XX by XXX to fix test failure
    // assertTrue("Some important assert", condition);
    }
    catch(Throwable t)
    {
    // Don't let anything fail this test!
    }
    }



    Here's another example of a QA WTF:

    At company that I worked for the QA department could not get the system being developed to start up and run reliably (once they got a reasonable number of computers logged in all kinds of errors started appearing).

    They fixed the problem by firing the QA manager, and eliminating QA.
  • None 2007-05-25 13:51
    NotanEnglishMajor:
    _js_:
    I like how Alex equates thin people with good programmers, and says fat people plain suck at programming.

    Because it's true.


    Yes of course, and all generalizations are false!


    To be fair, obesity is positively correlated to intelligence. So I would surmise that lower average intelligence would impact their skill. (And it is linked to higher incidence of dementia).

    Further, it limits mobility and communication, both useful skills for a programmer. Maybe more important than programming itself.

    And finally, in many cases it is an indicator that the person may be lazy or lack motivation. Obviously, some people may have legitimate reasons for being obese, and are protected under the ADA.

    If it was legal, I would probably hold being obese against a job candidate (as a low-to-mild indicator of possible poor performance). As it is now, I try to avoid that bias, but obviously, it probably creeps in to my evaluations.

    (And I'm not trying to claim that ALL fat people are stupid and bad programmers. Now THAT would be a WTF. ;P)
  • WasteOfAmmo 2007-05-25 14:12
    Although I appreciate the points that the poster is trying to make the assumptions about the problems with Gallanthotep's pyramid are proven wrong by actual history:

    * First and foremost, it’s probably not even possible to build an Egyptian-style pyramid sideways. A pyramid is a three-dimensional shape (the diagram/analogy assumes it’s a triangle), and adding to a face would make it ruin its nice, square base.
    * Secondly, a foundation must be laid prior to construction. I would imagine that constantly changing and adding to the building’s foundation in the middle of construction is a bad idea. I doubt such a building could last a few seasons, let alone a few millennia.
    * Thirdly, the intricate tunnels, rooms, and corridors within a pyramid would be pretty hard to plan out if the size of the building constantly changed. It’d probably end up looking pretty ridiculous once the pyramid was finally complete.

    Although not built exactly as the diagram shows there is at least one pyramid that was enlarged a few times. Look up the "stepped pyramid"; one of the first pyramids built (http://www.ancient-egypt.org/topography/saqqara/netjerikhet/pyramid.html).

    Also as another poster commented pyramids have been changed half way through building such as the "bent pyramid".
  • F.M. 2007-05-25 14:21
    Well, I read it all, up to this point and found it interesting.

    First, coding IS NOT HARD, actually it is quite easy. Of course I have been doing it longer than most of you have been alive (I guess, judging by the number of VB, Java, and C# comments I see on this board).

    Somewhere along the way it was decided that you don't actually have to understand what your code does, as long as you can make it function. "the compiler will optimize it for me" attitude.

    I have actually had to explain the concept of a bitmask to a college educated programmer, with multiple skills listed on his resume. This is unacceptable.

    I am also one of those kind of people who will say "logical shift left" when someone is standing in my way, and I get really annoyed if they don't understand that I want them to move.

    That being said, no methodology will help bad coding. Thats it, period, end of story. When did we forget that 10% of a programmers work is to actually write the code and the other 90% is to clean it up and make it "right". Most of the code I see that is considered "good and proper" makes me want to return my lunch via multiple orifices. You should all be ashamed.

    Push that on to your stack and never return. Its all a bunch of management buzzword overkill spawned by the 7 habits, or 12 steps or 4 quadrants, or whatever. Just go away, leave me alone and I will turn that steaming pile of specifications into what the customer REALLY wanted, but was too stupid to articulate.

    And you are correct, I don't mentor junior programmers, they make my brain hurt more than visual basic (and I don't have a spare 20 years to bring them up to speed).

    Sorry for the rant, I just hate that cr** (lean, six, etc, it's all the same).

    And yes, I have coded for mil spec.
  • rbriem 2007-05-25 14:32
    superted:
    It'd be nice if there was a way to know that this was an opinion essay, not a normal WTF. Could you tag these differently, like the Error'd? Or maybe tag the normal WTF. I enjoy the WTFs, but I would prefer to skip these.


    Note the beginning of paragraph 2:

    In lieu of a standard Worse Than Failure article, I'd like to discuss the latest craze ...


    But you're right. Hey Alex, can you put a "blink" tag on these?
  • sol 2007-05-25 14:36
    I'm no C or even C++ guru although I can at least program in the later and COBOL, but lets face it we are dealing with the VB generation here. Most of the programmers out there program in VB or they started there. And hey that is fine, but even VB can be made opti. Sure you have to actually type the code to cast things yourself and so on to get the best performance, but isn't that my job to type code?

    So, I agree with you, but I think so called RAD VB actually helps programmers be lazy and write sloppy code. And, maybe that is the point here maybe if you don't understand XP/Agile and have a plan you end up with a mess. It really comes down to defining requirements and standards more than Agile vs Bottom Up or Top Down.

    I work on a project that doesn't compile if you turn on Option Strict you know... these is the world we have to work in.. can I get a YAY

    Coding may not be hard but for some people doing thing all the way is... you know things like casting operation, checking for null, using stored procedures, actually checking if a user should be able to do that...


    F.M.:
    Well, I read it all, up to this point and found it interesting.

    First, coding IS NOT HARD, actually it is quite easy. Of course I have been doing it longer than most of you have been alive (I guess, judging by the number of VB, Java, and C# comments I see on this board).

    Somewhere along the way it was decided that you don't actually have to understand what your code does, as long as you can make it function. "the compiler will optimize it for me" attitude.

    I have actually had to explain the concept of a bitmask to a college educated programmer, with multiple skills listed on his resume. This is unacceptable.

    I am also one of those kind of people who will say "logical shift left" when someone is standing in my way, and I get really annoyed if they don't understand that I want them to move.

    That being said, no methodology will help bad coding. Thats it, period, end of story. When did we forget that 10% of a programmers work is to actually write the code and the other 90% is to clean it up and make it "right". Most of the code I see that is considered "good and proper" makes me want to return my lunch via multiple orifices. You should all be ashamed.

    Push that on to your stack and never return. Its all a bunch of management buzzword overkill spawned by the 7 habits, or 12 steps or 4 quadrants, or whatever. Just go away, leave me alone and I will turn that steaming pile of specifications into what the customer REALLY wanted, but was too stupid to articulate.

    And you are correct, I don't mentor junior programmers, they make my brain hurt more than visual basic (and I don't have a spare 20 years to bring them up to speed).

    Sorry for the rant, I just hate that cr** (lean, six, etc, it's all the same).

    And yes, I have coded for mil spec.
  • J. B. Rainsberger 2007-05-25 14:48
    I didn't read all the comments, so if I repeat someone, go easy on me.

    I think I can summarize the article: agile doesn't help all projects ship, so it doesn't work. If I got that wrong, ignore the rest; if you think that's accurate, consider reading on.

    Agile works exactly because it doesn't try to help all projects. Where agile helps, it amplifies good work and shines a light on areas to improve. You just had an article about people doing nothing, but hiding in government projects. An agile organization wouldn't let that happen; it would uncover Gustavo, which the author seems to think would be a good thing.

    Now agile uncovers many problems and can't solve them all, because some of those problems involve poor performers. The claim here is that agile doesn't help poor performers, and that's the loveliest kind of bullsh*t. Agile is largely about learning, and if poor performers learn, they have a chance to become good performers. Can agile make people learn? No, but nothing can.

    So are other methods better because they don't force us to confront the question "what should we do with Gustavo?"?
  • J. B. Rainsberger 2007-05-25 14:52

    Well, I read it all, up to this point and found it interesting.

    First, coding IS NOT HARD, actually it is quite easy. Of course I have been doing it longer than most of you have been alive (I guess, judging by the number of VB, Java, and C# comments I see on this board).

    Somewhere along the way it was decided that you don't actually have to understand what your code does, as long as you can make it function. "the compiler will optimize it for me" attitude.

    I have actually had to explain the concept of a bitmask to a college educated programmer, with multiple skills listed on his resume. This is unacceptable.

    I am also one of those kind of people who will say "logical shift left" when someone is standing in my way, and I get really annoyed if they don't understand that I want them to move.

    That being said, no methodology will help bad coding. Thats it, period, end of story. When did we forget that 10% of a programmers work is to actually write the code and the other 90% is to clean it up and make it "right". Most of the code I see that is considered "good and proper" makes me want to return my lunch via multiple orifices. You should all be ashamed.

    Push that on to your stack and never return. Its all a bunch of management buzzword overkill spawned by the 7 habits, or 12 steps or 4 quadrants, or whatever. Just go away, leave me alone and I will turn that steaming pile of specifications into what the customer REALLY wanted, but was too stupid to articulate.

    And you are correct, I don't mentor junior programmers, they make my brain hurt more than visual basic (and I don't have a spare 20 years to bring them up to speed).

    Sorry for the rant, I just hate that cr** (lean, six, etc, it's all the same).

    And yes, I have coded for mil spec.


    A perfect example: agile wouldn't fit this person, but at the same time, no-one should force this person to try to be agile. Live and let live. As long as this person doesn't mind me (on another team somewhere) trying to collaborate with the customer instead of calling him "stupid", or trying to mentor juniors instead of avoiding them, we can still have beer together on Friday. An agile organization wouldn't force this guy to be agile; it would recognize his value, figure out how to let him do his work, tell him how he would be measured, then let him succeed. He can't be on my team, but I'd be happy to help him make me money.
  • Eeve 2007-05-25 15:09
    The real question in this article is why do so many programmers suck and how can we help them?

    The answer is pretty clear from my perspective. They suck because they were never taught how to do it right. How to code for quality from the ground up.

    Here's a little insight. My home city has a university with a very popular computer science program. We get thousands of students entering the program each year. A majority of these are people comming from around the world to go to take this CS program. (Not cause it's good, but cause it's cheap). Many from Hong Kong and India come to this university.

    I went to this CS program. I took the 4 year honours degree program. (there is also a 3 year general degree). Through all my computer courses and practical labs, my tests, assignments, books and lessons, there was never, ever, even ONE mention of how to write for quality. No teacher every cared about it. No marks were lost for ugly code. If it worked bug free you got full marks.

    Read what I'm saying very carefully: In all my computer courses in a 4 year honours bachelor of computer science degree program there was not one single mention of quality code. And I went to all my classes and read all the books/notes and did all the homework. Yeah I was a nerd. BUT, doesn't this tell you something? I graduated only 4 years ago... things may have changed since then but I doubt it.

    So... there you have it. Those with the university edumakations are supposed to be good with the theory and the high level design considerations (like quality). Consider the number of people with smaller certifications or a few college level courses and the number of self-taught programmers and I'm sure the number of people who have had no instruction on quality gets even bigger.

    I didn't start caring about quality until I got my first real programming job with a guy who would hang me up by my fingers if I wrote ugly code. Called it to my face. That got me turned around real quick.
  • serge-nn 2007-05-25 15:10
    Anonymous:
    serge-nn:
    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 know what they are, but not what you mean.

    "Monochrome" means single-coloured. CGA stands for Colour Graphics Adaptor. They're 2 different things. One for monochrome displays. One for colour displays (even though the number of colours is very limited -- 16?). How come you can mix these 2 things together as "monochrome CGA"?


    It was so long ago, but I remember for sure I had a CGA, with a green-on-black monitor displaying colors as shades of green, and the whole thing was made in Bulgaria. I should be more clear on that, but that's not the point, though.
    We were forced into pair programming long before agile and XP were born. Other concepts, "Refactor mersilessly", "unit-test" and "have a user around" also were practiced.
    Most of "silver bullets" flying around are not anything new -- people just invent buzz words and sell the whole package as a panacea.
    Software is just too complicated to expect improvements from tools and methodologies in orders of magnitude. It's not like an excavator can dig a trench 100 times faster than a man with a shovel. Neither it's like 100 men digging 100 times faster than one. Everything Brooks had said all about it, still holds true.
  • Kiriai 2007-05-25 15:13
    Eeve:
    The real question in this article is why do so many programmers suck and how can we help them?

    The answer is pretty clear from my perspective. They suck because they were never taught how to do it right. How to code for quality from the ground up.

    Here's a little insight. My home city has a university with a very popular computer science program. We get thousands of students entering the program each year. A majority of these are people comming from around the world to go to take this CS program. (Not cause it's good, but cause it's cheap). Many from Hong Kong and India come to this university.

    I went to this CS program. I took the 4 year honours degree program. (there is also a 3 year general degree). Through all my computer courses and practical labs, my tests, assignments, books and lessons, there was never, ever, even ONE mention of how to write for quality. No teacher every cared about it. No marks were lost for ugly code. If it worked bug free you got full marks.

    Read what I'm saying very carefully: In all my computer courses in a 4 year honours bachelor of computer science degree program there was not one single mention of quality code. And I went to all my classes and read all the books/notes and did all the homework. Yeah I was a nerd. BUT, doesn't this tell you something? I graduated only 4 years ago... things may have changed since then but I doubt it.

    So... there you have it. Those with the university edumakations are supposed to be good with the theory and the high level design considerations (like quality). Consider the number of people with smaller certifications or a few college level courses and the number of self-taught programmers and I'm sure the number of people who have had no instruction on quality gets even bigger.

    I didn't start caring about quality until I got my first real programming job with a guy who would hang me up by my fingers if I wrote ugly code. Called it to my face. That got me turned around real quick.


    At my school, I didn't turn in a significant project that was bug-free or actually met the requirements of the assignment. Be lucky they checked for correctness.

    And style is not the same thing as quality. Correctness is the bigger concern. Style and consistency are what you should learn in an acquaintanceship. College is for the deep theory.
  • Kid 2007-05-25 15:14
    Maybe the article was named wrong, because I don't see a slam of Agile methodology, I see a slam of assuming that adopting agile methodology is a surefire method of making good software, which is a sentiment which seems to be repeated often enough.

    By the way, can all of you "agile" developers send me your "constant communicating" clients? Ours give us a vague spec and tell us to code to that. Clarifications are redirected to the spec.

    The solution to that is pretty easy, though. Do the design, have them sign off on the design, and program to the design.

    See? Design at the front of the process has a very good use. Maybe we should trademark this and write lots of books on it...
  • serge-nn 2007-05-25 15:56
    Eeve:
    The real question in this article is why do so many programmers suck and how can we help them?

    The answer is pretty clear from my perspective. They suck because they were never taught how to do it right. How to code for quality from the ground up.



    Nobody taught us students to read code, ever. It was all about writing code. Nobody told us that maintenance (fixing defects and adding functionality) costs more than initial software creation. Any assignment you get in a typical CS course is a stand-alone task, implemented by a single programmer, almost never a team. So, there is no wonder that great majority of production code is a collection of riddles and puzzles.
    Still, my managers' mantra is "If it works, don't fix it". Then they come and demand from me five new features, all due tomorrow. "What do you mean, you need to refactor first? We have a deadline. Customer wants it delivered yesterday!" Then the customer, pissed off by numerous (and recurring) bugs, turns to another vendor. "We didn't have enough features", says the manager sadly. "We have to do better next time."
    Sorry, can't help it. Captcha : dubya
  • Dustin_00 2007-05-25 16:37
    I look at methodologies like I do programming languages: you have many to choose from. Use the right tool for the problem at hand.

    When I, as a dev, am tasked with creating a new tool and management only has a vague idea of what it should do, I find it far better to create the primary single function for them to play with. Then I add on to it as management begins to use it and realizes what they actually need.

    At times you find you must make painful changes to the database structure (mess with the foundation) and yes, it can take a lot of time to redo your foundation. But I look at the work done to be R&D that you happened to also get value out of -- both production work and marketing as you now have everybody on the same page of what the tool can currently do and what the next step should be.

    But then again, I'm a dev with a collection of customers and no manager, so maybe my life is a little weird.
  • anonymous 2007-05-25 16:47
    poochner:
    Don't confuse CS with IT, please. They're not the same thing at all. There's not much of a market for CS people outside academia (Google is one place). They certainly don't program for a living.


    Don't confuse IT with software engineering. IT people don't program for a living, either - when they do, their code ends up on this site.
  • real_aardvark 2007-05-25 16:58
    Angel:
    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.
    ...snip ...

    (I apologise for cutting the rest out: anyone interested should look up the OP.)

    You were "taught" 'XP' in "university"?

    Jesus Christ. Which school/college/university would that be? I'm not for a moment suggesting that you have a problem. It is, however, difficult to imagine a University setting that would voluntarily prostrate even CompSci 101 to XP, Agile, Robots-R-Us, "Waterfall (a much-misunderstood methodology, in that it never existed in the first place), or whatever.

    What's wrong with a Computer Science course that actually teaches Computer Science? Not some god-awful marketing piece of crap that might even be beneficial, despite itself ...

    I merely ask.

    PS The one I truly despise is the Carnegie Mellon Capability Model. But that's just me. And a shedload of experience.
  • Richard Asscock III 2007-05-25 17:00
    Former good programmer...8 years ago, I made half of what I make now, but I worked twice as hard then as I do now.

    There's another problem where the good programmers work with the bad and learn to ease off. Why do twice the workload and be answerboy (or goto guy) when you'll get the same 3% raise as the bad programmer?

    I agree we need tests/certifications, but a little pay-for-performance thrown in wouldn't hurt.

    What do I do now? You know the answer. I consult, however, I usually end up spending half of my time showing the client how to use Ctrl-C and Ctrl-V or how to scroll down in any app. Unbelieveable how many people in 2007 will write it out from one app to another, or constantly click the down arrow button in Excel to move down to the 1000th record.

    Yes, I have a bad attitude.
    Dick Asscock
  • real_aardvark 2007-05-25 17:41
    Nyuserre:
    Liberator:
    Imagine the whole world laughing at all those unfinished pyramids of long-dead Pharaohs...


    Imagine Menkaure's son Shepseskaf completing his father's pyramid after his death.

    Or perhaps Neferirkare: "But he died before the complex was completed. The work on the pyramid was stopped, and the funerary complex quickly finished, using mudbrick and tree instead of stone." (But good old Nyuserre later refactored it for his dear ol' dad.)

    Not sure what my point is.

    Nor me, but it's the best that anybody has come up with so far.
  • real_aardvark 2007-05-25 17:52
    F.M.:
    Well, I read it all, up to this point and found it interesting.

    First, coding IS NOT HARD, actually it is quite easy. Of course I have been doing it longer than most of you have been alive (I guess, judging by the number of VB, Java, and C# comments I see on this board).

    How long is long, sweetie?
    F.M.:
    And yes, I have coded for mil spec.

    Well, that's twenty-odd years of wasted time, then.

    Can we get back to the point at issue, please?
  • chrismcb 2007-05-25 18:48
    gwenhwyfaer:
    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 ;)


    It wasn't entirely flame bait. I just don't get it.
    I'll gloss over the first point about "maintaining a monopoly ... isn't reasonable way of living" Becuase I've made a living doing just that, and that is also how other people in other industries are making a living (although that may be changing because most people think its ok to steal music/movies)

    This is the part that I don't understand "... and frankly people should be paid damnd well [for writing software]" Great, but the in the world of Open Source/Free Software. WHO is going to pay for it?
    Company GidegetMaker might hire you to modify some open source software. So YOU make some money, but what about the people who wrote the base that you are modifying? Of course your changes won't go back out into the wild (why would Company GidgetMaker pay good money for custom software, that their competitiors can now get for free?)

    Well you can make money on the service/maintence end. Which promotes making more buggy/hard to use software. There is no incentive to write good clean software that JUST WORKS (because if it Just Worked there would be no service calls)

    Software is the only industry that I know of, where people IN the industry think its a good idea to give their product away for free(more than just samples or ad supported). I just don't get it.
  • chrismcb 2007-05-25 18:53
    serge-nn:
    Pair programming really reduces mistakes made by bad programmers - with the price of a good programmer slowed down, getting bored and frustrated.


    The reminds me of a time when I was helping another program debug is buggy code (With an average of about 1.5 bugs per line!)

    So he is sitting at the keyboard, I'm looking over his shoulder. He hits the step button. Then turns and looks at me, and asks "Should we look at the value of this variable?"
    Sure hover over it, what is its value?
    Ok, should we step into this function?

    3 HOURS of that... That was my penance for not writing the function for him when he asked me.
  • Steve 2007-05-25 19:15
    >>most people are average, below average, or just plain suck.

    From what I have observed i agree with that. But shouldn't it follow that the average person is, errr, average?
  • chrismcb 2007-05-25 19:17
    None:

    To be fair, obesity is positively correlated to intelligence. So I would surmise that lower average intelligence would impact their skill. (And it is linked to higher incidence of dementia).

    Further, it limits mobility and communication, both useful skills for a programmer. Maybe more important than programming itself.

    And finally, in many cases it is an indicator that the person may be lazy or lack motivation. Obviously, some people may have legitimate reasons for being obese, and are protected under the ADA.

    If it was legal, I would probably hold being obese against a job candidate (as a low-to-mild indicator of possible poor performance). As it is now, I try to avoid that bias, but obviously, it probably creeps in to my evaluations.

    (And I'm not trying to claim that ALL fat people are stupid and bad programmers. Now THAT would be a WTF. ;P)


    WTF? Are you trolling?
    Obesity if NOT positively correlated to intelligence.
    I pretty much spend 95% of my time sitting on my fat ass in front of my computer programming (excet to walk to the kitchen) WHY do I need to be mobile?
    How does being FAT limit communication?

    As for being lazy, that is one of the best traits you want in a programmer. IMHO. A good programmer is lazy, and knows how to figure out how to get the computer to do the work for him. Work smarter not harder.
  • serge-nn 2007-05-25 21:03
    [quote user="chrismcb"] It wasn't entirely flame bait. I just don't get it.
    I'll gloss over the first point about "maintaining a monopoly ... isn't reasonable way of living" Becuase I've made a living doing just that, and that is also how other people in other industries are making a living (although that may be changing because most people think its ok to steal music/movies)[quote]

    Charging for your products and services doesn't neccessarily mean you have to be a monopoly. Competition is good for customers. Also, a lot of people are forced into "stealing" by insane DRM techniques that limit fair use or are plain evil, like the famous Sony's rootkit.

    [quote user="chrismcb"] ... Company GidegetMaker might hire you to modify some open source software. So YOU make some money, but what about the people who wrote the base that you are modifying?[/quote]
    The OpenSource creators hope that they will be the ones hired and paid big bucks for customizations. Which proves your point - there is no incentive to write something intuitive and just working. Which is why open source s/w doesn't.

    [quote user="chrismcb"] Of course your changes won't go back out into the wild (why would Company GidgetMaker pay good money for custom software, that their competitiors can now get for free?)[/quote]

    Because GPL says so (your work is derived from GPL'ed source code), and if they don't, they might face the lawyers some day. There are precedents.

    [quote user="chrismcb"] Software is the only industry that I know of, where people IN the industry think its a good idea to give their product away for free(more than just samples or ad supported). I just don't get it.[/quote]

    Nobody is giving away anything. It's a shift of business model. I don't know why the inkjet manufacturers, like Epson or HP don't give away the printers -- the cartridges costs are much greater than the printers prices, over the lifetime of a printer.
    Cell companies subsudize the phones, in exchange for 1-2 years contract commitment.
    Free cheeze only happens to be.... right, in the mouse trap.
  • Dan 2007-05-25 21:27
    This article was not very good.

    If you are really concerned about bad developers, surely the constant reviews, updates, and morning planning meetings will provide enough points to spot them, and take appropriate action? Pair programming will also spot these issues, and offer peer-driven knowledge sharing.

    Unless your entire development team are useless. But then what kind of software were they ever going to produce?

    At the moment I am involved in a project where the business requirements are untried and untested even in a paper-based system as we go into our initial iterations (there was a previous system in place, but this is changing as we speak). The first iterations are going to let us and our clients see what they have missing in their own process, as well as what is possible for future iterations.

    We have set deadlines (it is a funded project, so we have limited salaries coming out of that), we have points along the way we have to hit (it is a work-based-learning project, so people will be on placements at specific times). If we were to simply analyse, and model the paper based system they have created, we _already_ have proof that we would have produced functional, but useless software.

    Aside from the fact that the pyramid analogy is a poor one, I don't really see much indication that an agile development methodology is a bad plan.

    I am not telling you the CAPTCHA because it makes me feel naughty.
  • gwenhwyfaer 2007-05-25 21:31
    chrismcb:
    It wasn't entirely flame bait. I just don't get it.

    Well, I'll see if I can explain better then. I'm not seeking to convert you, or anyone, to my position; I'm just trying to put the case, so that you can disagree from a more informed perspective. (Also, the below is only my position; I can't speak for anyone else.)

    I'll gloss over the first point about "maintaining a monopoly ... isn't reasonable way of living" Becuase I've made a living doing just that

    Perhaps I would have made my meaning clearer if I'd gone with my original choice of "moral" instead of toning it down to "reasonable"? You may get even more upset at having your actions described as immoral - most people seem to, for some reason - but similarly, I believe that cheating on your partner is also immoral, and that people should not be protected from the consequences of doing so - but I don't believe anyone should be prevented from being unfaithful.

    Also, if you work to perpetuate the idea that the step that really brings in the money for software production is the duplication of the end product, what happens is that you end up with a market where the actual quality of the product being sold doesn't matter, only the volume shifted, and the work that goes into that product is seen as essentially worthless. You also get an incredibly risk-averse industry. It's funny you mention the entertainment industry, because you can see that exactly that has happened there - the only thing that matters is shifting units, therefore the biggest players have oriented themselves exclusively towards that product which will shift as many units as possible. (That model works for factory output, where you're basically buying a physical unit where the difficulty of creating the product is reflected in the difficulty of duplicating it - but for essentially a string of numbers, stored on a medium optimised for cheap, fast reproduction? It doesn't make economic sense.)

    The economic reality of the entertainment and software industries is that they are service industries; anything over and above the provision of that service rests on the artificial monopoly granted by the concept of copyright. And interestingly enough, the problems with proprietary software, that free software seeks to overcome, are mirrored by the issues that cropped up over sampling in the music industry - and some artists who choose to say "sample me freely, I don't mind" then find their record companies saying "actually, we do mind, and we own it".

    ...But all of that is a side issue compared with the morality point - and it's the morality of proprietary software with which I have an issue.

    (although that may be changing because most people think its ok to steal music/movies)

    If enough people think so, eventually it will become legal. Majority rule is founded upon the idea that the majority make the rules; and artificially created rights are always vulnerable to shifts in the ethical environment that allowed them to be created.

    This is the part that I don't understand "... and frankly people should be paid damnd well [for writing software]" Great, but the in the world of Open Source/Free Software. WHO is going to pay for it? Company GidegetMaker might hire you to modify some open source software. So YOU make some money, but what about the people who wrote the base that you are modifying?

    Well, they presumably felt they got paid enough - either in money, or in other rewards - when they wrote that base, didn't they? Otherwise they would have chosen a different licence - or simply kept it to themselves altogether. When someone releases something under specific terms, they have expressly stated their position; I wouldn't presume to second-guess them on that. Likewise, when you use that software, you implicitly agree to the terms they have set for its use - because you always have the choice of using or creating an alternative.

    Of course your changes won't go back out into the wild (why would Company GidgetMaker pay good money for custom software, that their competitiors can now get for free?)

    That presumes that their needs are identical to those of their competitors. Besides, they have the right not to distribute the changes they paid to have made, if that was the basis on which they agreed that - but if they do distribute them, they have to do so under terms compatible with the original licences.

    You're also overlooking one very good economic reason why they might consent to the changes being released - they don't have to maintain a codebase of their own; they can automatically benefit from any updates made to other parts of the tree, without having to figure out how to shoehorn them into their own, ever more divergent copy. And they get that ongoing maintenance for free... provided someone else is paying the maintainer, of course.

    Well you can make money on the service/maintence end. Which promotes making more buggy/hard to use software. There is no incentive to write good clean software that JUST WORKS (because if it Just Worked there would be no service calls)

    I do believe you're suggesting that the only possible incentive for any action is financial...? That's just silly.

    Nonetheless, writing buggy software on purpose tends to be one of those things that circumscribes a person's ability to continue to make money at what they do. Integrity is worth paying for, and noticeable when absent.

    Software is the only industry that I know of, where people IN the industry think its a good idea to give their product away for free(more than just samples or ad supported). I just don't get it.

    That's because you're thinking of the product as the only thing that's worth anything. Think of it as a byproduct of the service rendered - think of a customised piece of software as a newly-working central heating system in the middle of winter, rather than as just a length of anonymous piping.

    After all, in the service model, once you've been paid the call-out rate, the end product is cheap, and morally belongs to the customer anyway; and even in the mass distribution model, the customer still has the right to fix their own engine if they choose - the source code is the program's Haynes manual. As for competitors - does a competent plumber fear that all the other plumbers in town will drive him out of business? Do Fear Factory worry that Pitchshifter will steal their fanbase?
  • gwenhwyfaer 2007-05-25 21:41
    chrismcb:
    None:

    To be fair, obesity is positively correlated to intelligence.


    WTF? Are you trolling?
    Obesity if NOT positively correlated to intelligence.

    I do believe that both you and the person you're replying to are confused as to what "positive correlation" means... see here for an example.

    As for being lazy, that is one of the best traits you want in a programmer. IMHO.

    I know what you mean, but I'm not sure "lazy" really covers it. What you probably want is a programmer with ADD (since we're slinging around the stereotypes with gay abandon) - someone who can only ever bear to do anything once, no matter how trivial, but will happily spend ten hours figuring out how to do a 2-minute task programmatically to avoid having to do it 50 times by hand. After all, time passes relatively; ten quick productive hours you can look back on with pride will always take less time than two irretrievable hours of having the corner of your soul scratched away by a persistent earwig.
  • gwenhwyfaer 2007-05-25 21:44
    chrismcb:
    The reminds me of a time when I was helping another program debug is buggy code (With an average of about 1.5 bugs per line!)

    So he is sitting at the keyboard, I'm looking over his shoulder. He hits the step button. Then turns and looks at me, and asks "Should we look at the value of this variable?"
    Sure hover over it, what is its value?
    Ok, should we step into this function?

    3 HOURS of that... That was my penance for not writing the function for him when he asked me.

    Thus proving the old adage: Give a man a fish, and you've fed him for a day; try to teach him to fish, and you might end up abbreviating his life - either way, his hunger will be abated soon.
  • Manuel Klimek 2007-05-26 03:06
    Yes. You always think that when you hear of agile. I myself did. See Do you understand XP?
  • Robbie 2007-05-26 03:37

    > Business processes change constantly
    I'd say that Agile hides the real consequences of changing a business process. It is really just encouraging people to change their business process when perhaps they don't really need to.

    This debate is really beyond software. It's about constantly changing the expectations of your workforce.
  • marci 2007-05-26 10:57
    that is funny!

    The reason is, I have seen that type of test. Once my partner and I saw it, we brought it to the group to point out that this type of code is EXACTLY what we don't want (collective code ownership at its best). We asked around, the culprit was found and was charged with fixing it. The nice thing was: in an Agile shop, the customers were never too far away. We asked them if the functionality was really needed. We explained what the problem was and, as a team, decided how to handle the test. In the end there were at least 3 xP practices at work.
  • Dave Rooney 2007-05-26 11:16
    > I'd say that Agile hides the real consequences of
    > changing a business process. It is really just
    > encouraging people to change their business process
    > when perhaps they don't really need to.

    Not at all! If a business process or rule changes, the team doesn't just blindly go ahead and make the change. They all sit down (business people included), determine what must be done to implement the change and estimate the amount of work. The business people are not allowed to influence the estimates, and the development people aren't allowed to dictate priorities.

    In the end, though, the estimates may cause the business people to rethink the change - can it be made smaller or simpler, can it be done in increments over time, etc. If the change has a high enough priority for the business and they're willing to pay the price for the change, then the development people just need to suck it up and do it. After all, they're supporting the business and not vice versa.

    Remember, this is a supposed to be a collaborative process. If it isn't, you should say so and possibly get some outside help.
  • rgz 2007-05-26 16:09
    anne:
    God bless you. When I saw "Agile", I thought "Oh, no, it's going to be a post on fad software methodologies."

    And then you made the analogy with diets. Brilliant. I couldn't agree more.

    To those of you defending agile, I'm sure when it's implemented by a strong team, it works -- but nothing will change the fact that you need good developers to write good code, and it's still hard.

    Thank you!!!


    The whole article is a fucking TROLL.

    That being said. I find this argument really stupid. So you don't use agile because it requires good people? Ok Aglie is not for you, but why are you hiring morons anyway? Because they are cheaper/numerous?

    Then let's say that for once a company focus on programmer quality instead of quantity. Are we still supposed to be bound by the same rules that your army of incompetents?

    The true is that all but the simplest projects change and when they change, you better be prepared for it.

    It is possible to change a waterfall designed project, but it is not better at it Agile Programing.
  • miraculix.x 2007-05-26 16:54
    "The worst is to take a good idea and build a believe structure on top of it" - I guess that's really what's wrong about the Agile movement. It's also what's wrong with the RUP, XP, J2EE, .NET, MDA, MDD, TDD and-what-have-you crowd.

    The biggest problem really is that in your average corporation you get people to look at whatever methodology you put in front of them, and they will make it complicated, guaranteed. So if you tell them to go Agile, they will deep-dive the relevant literature and create a ton of rules and documents to be adhered to. More often contradicting itself than not, that's where the problem starts.

    If nothing else, Agile has put the notion to managers that software is better built incrementally...


    (not sure who came up with the quote, but I am rather inclined to believe I read it in one of late Douglas Adams' books).
  • Madgreek65 2007-05-26 18:06
    I agree with some of your comments but I disagree with your overall assessment that agile cannot work. First of all, a methodology is a tool and you must use the right tool for the job. If your project is to implement a new email system, then an agile methodology is probably not the right approach. But if you are developing software, agile can be a very productive tool to get the job done. Any time you read about agile methodologies failing, it is typically the failure of people that are the cause not the methodology.
  • cklam 2007-05-27 02:12
    I have always seen some conceptual issues with Agile Development and XP - these are:

    * Scope of work: a lot of customers do not want contracts where the scope of work and the end result is not nailed down. Imagine: you have a contract stating that X numbers of man hours are to be spent at Y hourly rate without having (more than a remote or any) idea on the result. Come on: consultants get these kind of contracts, software dev people don't (unless you have consultants who do software dev work -and that is a completely different issue in itself). No cover-your-own-ass-manager type is going to agree to that kind of thing. In Germany, no sane developer would accept such a contract with any kind of deliverable defined - under the german legal situation the dev would be responsible for eternity to fix the thing at their own cost one the budget runs out. No customer in Germany would issue such a contract without a deliverable defined (unless it is a pure support-type contract. The point I am trying to make here is that open-end type of contracts without any delverable specs are not liked by customers.

    * Before Agile and XP, there was Rapid Prototyping. IMHO, a good enough system analysis tool but not something that you want to put into production. I consider Agile and XP as similar methodoligies: very good at ferreting out business processes and requirements - but you have to stop at one point and develop a real product (and can the prototype if necessary). Agile and XP are - as far as I am concerned - OK enough for system analysis work - that's it.

    * XP and especially Agile require a lot of customer commitment. Notably, this most important when the customer is not clear about his own requirements. The customer needs to commit a lot of their employee's time to make Agile and XP work. Now from my own experience I have observed that the customers who really do not initially know what they want are (very) often the same customers who do not know what they doing in their business and are totally hectic and overworked - in other words the employees there do not need a bunch of dev people interfering with everybody's time regardless what their management says. Crappy customers usually make for crappy projects.

    OK, Agilistas: now go and kick my ass.
  • cklam 2007-05-27 02:21
    Jon W:


    < SNIP >

    - 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?


    Nothing. But I do not have be Agile for that; this is just plain old good-fashoned common sense.
  • cklam 2007-05-27 02:34
    bif:
    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.


    Faith is for religions - we are software developers: that means we approach our work subjects as craftsmen, artisans and (in rare cases) engineers. We do not approach our work subjects as monks, pastors or priests because ideology get in the way of the reality on the ground.

    Enough said.
  • cklam 2007-05-27 02:41
    pirannia:
    NotManagementMaterial:

    Simple formula: less talk + more code = product success


    You're so wrong here, on so many levels...


    Concur - software development is about communicating: with your customers/users, your fellow devs, your QA people, your testers. You also get to code.
  • Doug 2007-05-27 04:04
    The analogy is ridiculous. You may as well have likened cars to badgers.
  • Tim Lesher 2007-05-27 10:57
    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?


    I'm not sure where you're getting that assumption. Iterative refinement and constant refactoring of the process itself is part and parcel of any agile or iterative process.
  • brazzy 2007-05-28 05:44
    real_aardvark:
    Proof, please, if you would be so kind. As a gedankenexperiment:

    * What happens when (not if) you pair two really bad programmers?

    I'd imagine that the resulting code would be crappy but still better than what each of them would have done on their own, since the second person should still be able to catch SOME errors, if not as many as a more competent guy.

    * What if BDUF (GIHTA, or, God, I Hate That Acronym) were to incorporate extensive unit tests? Shock, horror!

    What are you trying to get at? That it would benefit from them just as much? Sure. So what?


    * What if your Whig Theory of Programming is as unfounded as its equivalent in History, and constant refactoring means that crappy code merely gets churned into a different wodge of crappy code, now with hidden extra bugs?

    You don't refactor to meet your refactoring quota, you do it because you have identified some problem with the code. Identifying problems after the fact when you see the code working in context is much easier than expecting and avoiding them. As for the bugs introduced by refactoring, that's why you have automated tests.
  • Elite 2007-05-28 06:14
    --We all know that human capacity for handling complexity is limited

    This is the exact opposite of what I beleive. The human capacity to express things simply is limited. Any programmer can handle complex tasks with an overly complex solution (some relish in it). It takes the extraordinary programmer to do the simplest thing that could possibly work.
  • MblSH 2007-05-28 06:29
    >> Re:monoCGA
    > I know what they are, but not what you mean.

    Google monoCGA - back in USSR there really were configurations where CGA connected to a monochrome monitor, usually plain black and white one, and the colors looked dithered. And yes, CGA only had four colors
  • Steve Freeman 2007-05-28 15:21
    I wouldn't normally respond to flame bait like this, but I was actually inside the Cheops pyramid today so this must be fated...

    As others have pointed out, the metaphor is flawed but that doesn't really matter. What I find most interesting about the responses is that most of them are inward focussed -- on the developers.

    To me, the most effective feature of Agile is that developers and business people should (drum roll) talk to each other. Often. To make sure that things are heading in the right direction and to respond to any discoveries along the way. The other practices, such as TDD and pairing, are techniques to help me make sure that what I say is done really is Done, and to respond quickly when the direction changes or is clarified.
  • Markus Schaber 2007-05-29 07:28
    I fully agree that a good process won't help to get success when the developers are not good enough, but the other is also true.

    Having braindead processes will hinder good developers, and you have the warranty that the project won't succeed.
  • Trumpi 2007-05-29 11:22
    I see a lot of people bashing this article because they think that it bashed Agile Development. I did not get the impression that it was bashing Agile, but maybe I'm missing something.

    I think that the article says this: people think that they need this thing called "Agile" and they then adopt a new process. However, there are still people in the team who are not educated in Agile techniques. This is actually un-Agile, because Agile favours people over process.

    I found myself in a job where Agile was used as a marketing term to prospective clients. What I found there was that Agile meant no documentation and no process. Again, this is not Agile -- clearly there were people there who knew about this term "Agile", but did not know how it worked.
  • Peter Hundermark 2007-05-29 11:45
    The analogy used, like most between software and building, does not work well.

    Software is complex. Change is endemic. Therefore the process employed needs to be appropriate. This turns out to be a system with a feedback loop and a short cycle time. It allows stakeholders and the development team to work inspect small increments of built software and adapt as they understand more and as the environment changes around them.

    It's true that bad developers will deliver cr*p software. This will be true for every process. With a transparent, agile process you will get the bad news soon and you can then do something about it. With waterfall you'll p*ss bucketloads of money into the project before you find out it's doomed.

    Perhaps the lesson for agile evangelists is to stop using the same old, bad analogies.

    Peter
  • tamosius 2007-05-29 11:51
    Re: ...and the overwhelming majority of software developers (i.e. the less-than-good folks), Agile methodologies simply cannot work

    One of the Agile methodologies *requirements* is to have *less but better* developers.
  • Laura 2007-05-29 13:24
    Agile is actually pragmatic. Instead of playing games and pretending we are going to be able to get everything right the first time and forever after in one or two iterations, with full documentation (that of course will never become obsolete)....we accept the reality that the path to hell is paved with good intentions. Build what you need now, extend it as it is used because after your first release (no matter how thoroughly planned) users will want to add to it and/or change it and/or will have decided they didn't actually need it and/or will now see what the planning was all about and now want to introduce the actual features they needed. Create as much documentation as you need now, instead of a bunch of diagrams that will become obsolete nearly immediately. Test driven by the way is a design methodology, not a testing methodology. BTW I love the criticism that Agile doesn't produce enough documentation -- ask the person who offers that up how much documentation they produce with the methodology they prefer and the answer is usually little to none.
  • sammy 2007-05-29 14:26
    Perhaps I’m being a bit unfair nitpicking an Agile analogy. After all, the Agilistas contend that it works well and have whole handful of success stories to show for it. As for the cases of failure, the answer is overwhelmingly, “of course it didn’t work; the project didn’t have enough good people.”

    And therein lies the problem: most developers are not good. By the very definition of the word "good," most people are average, below average, or just plain suck. There’s a word to describe products designed for the masses that work only for some: defective.


    I started off being pretty jazzed about this post, but the farther I've gotten into it, the more disappointed I've grown.

    Alex, you're asserting that Agile(like) development methodologies are "defective" because they only work for good programmers.

    Either you think that the use of some kind - pick one - of methodology helps, or you don't. But, your paean to better education and quality control in the corps of developers out there aside, you can't seriously mean that these methodologies are "defective" just because it can't help bad coders.

    By that logic, an F-22 is defective because I can't fly one, and a Ferrari Enzo is defective because the proprietors of shady game companies wrap them around utility poles.
  • Sheik Yerbouti 2007-05-29 16:25
    As other people have pointed out, I stopped reading when I reached the idea of a pyramid with a square base. This is indeed a WTF, but probably not in the way that the author meant it. I suggest enrolling in an Agile programming class involving cubical blocks of concrete, the whips of overseers, and associated UFOs.
  • Stallina 2007-06-02 09:06
    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.

    Like everything else, a team must choose the right tool for the job -- if you have bad developers, and you can't get rid of them, don't try to use Agile. You'll fail.

    Or, worse, you'll "succeed" in creating horrible (but up-to-spec) software.


    Very good point, but...
    Really good developers are extremely difficult to find. In my company there are around 200 software developers, 6 or 7 architects, 10 managers/team leads, and i know around 60 of them. Now how many of them are good? None. Well there used to be one, but he stayed for less than 1 month then quit.

    From my experience (with a total of 6 employers), i can only remember one company who had a handful of really good people.

    Birds of a feather flock together.

    So what about me? I am NOT a good developer, but i know where i need to improve and am working hard at it. The only reason i'm staying in my current job is that it allows me to experiment with lots of stuff i want to learn. The sad thing is that not a single person around me could see the light.
  • John 2007-06-07 12:34
    It's all about design. If you have people who can do it, then up-front design is obviously the right thing to do. Good up-front designs do not remove flexibility and responsiveness, they actually improve it due to greater understanding of the problem domain.

    If you can't do design, then choosing between agile or waterfall is like choosing whether to barf in the sink or the bath - either way you'll end up with a mess to clean up and a bitter taste in your mouth.

    Software people who can't do design like to hide that fact so they advocate methodologies that provide impressive looking results early on and then paint over the cracks that show up later using religious sounding dogma.

    PS captcha is "stinky". How appropriate. Put those Kent Beck books back on the shelf and start learning engineering, people!
  • Tony 2007-08-22 16:03
    True, you do need good developers to write good code, and that's a key point, but what about everyone else you need to build a successful system, like testers, prodcut analysts and customers? Everyone seems hung up on developers. What are you going to build without input and how many of us have written code that works and integrates without rework. I'm not hung up on agile, I've seen it work and fail, but I am hung up on teams and eliminating waste in development efforts and that seems to be missing in the thread
  • Tony 2007-08-22 16:09
    I hope you're kidding. I'd like to see more talk 'about what needs to get done' and less code until you understand what you're doing. I think we have a few too many lines(*1000000) of unused or complex code floating around out there.
  • David Longstreet 2007-10-02 11:34
    I thought you would enjoy a paper I wrote and presented at several conferences.

    Agile Methods and Other Fairy Tales

    The link is http://www.SoftwareMetrics.Com/Agile

    http://www.SoftwareMetrics.Com/Agile

    David Longstreet
    Software Economist
    www.SoftwareMetrics.Com
  • Game programmer 2007-10-11 15:08
    We tried agile at a game company, and it bombed. Talk about tying up the hands of the superstar programmers, bogging them down in meetings, having them code to be ready for presentation instead of for customers. BLEH!

    It bombed big time... Mostly due to some people that couldn't stand others not doing things their way and trying to dominate the desgins and meetings. People just ended up with argument fatigue and gave in until they found another job to go to.
  • First and foremost... 2007-11-18 02:21
    First and foremost, it *is* possible to build a square pyramid sideways. Adding to two faces would add to its nice, square base.
  • Brian Berenbach 2007-11-25 22:59
    When I was an architect, many years ago, I built software based control systems and simulators for power plants. The systems would be installed during an outage, and if the startup of the plant was delayed, penalties ran about 1 million dollars per day. Needless to say the systems were in and up on time.

    What I have seen that causes failures (major overruns or cancellations) in big systems of all kinds is a lack of engineering knowledge. That is, the management of teams, the engineering of complex systems, the writing of unambiguous, correct and complete specifications, these are things that are neglected in university and consequently not understood by the computer science and other technical staff suddenly thrust into management positions.

    Furthermore, understanding how to successfully build large/and or complex software based systems is learned by OJT, not be reading a book or spending a week getting a certificate. If you have never apprenticed at a senior level on a large successful project then your chances of succeeding in a senior management position of such a project are drastically reduced (near zero). While no one would expect an architect to read a book on bridge building and then manage the construction of a large bridge over a river, in the wonderful world of software, such assumptions are commonplace, e.g. i read Booch's book, so I am all set to build a big OO system.

    I see agile as grasping at straws. That is, it is the placing of the seal of approval on a fudge, a grasping at straws.

    Yes, agile will work, where the final product is very, very malleable and the staff is small, e.g. people sitting in a room talking to each other. Other than that, agile cannot work by definition. A software architecture is a complex thing, as the amount of code that is written goes up linearly, the effort to refactor goes up exponentially. That is, unfortunately, the way it is.

    The only thing to date that has saved agile from a really, really bad reputation is the fact that the good lives on, and the bad (and believe me there is a lot of it) is buried with the accounting losses.

    And that, ladies and gentlemen, is just my opinion.
  • Pro-Pyramid 2007-11-30 09:21
    Alex,
    No analogy is perfect. The pyramid analogy is a useful tool for convincing people that conventional Waterfall methodologies are particularly problematic. Agile is an interesting alternative, all the same it's not specifically mentioned in Mayo-Smith's Information Week article.




  • Kelli 2007-12-10 22:11
    wow this is guy....screw this shit!
  • Mayo-Smith was ahead of his time. 2007-12-16 21:50
    Mayo-Smith's article doesn't mention Agile and predates the Agile fad by several years.
  • Andy Wong 2008-01-09 00:49
    Agile is good for understanding requirements and assist the customers to understand their own requirements. Agile can not help your programming and design skills. You have to be good first at programming and design, then you might be able to get benefits from agile practices.
  • spinLock 2008-02-20 16:01
    Loved the message, but this part is just plain wrong: "the only way to lose weight is to eat less and exercise more."

    The reality is that 'modern' food makes the vast majority of us fat (I know, I used to be in that majority). Now that I'm back to fresh fruits & veggies & home-cooked meat, I'm in the minority again.

    Exercise is good of course, but if you're using it to maintain a healthy body weight, then see the above paragraph. I'm finally slim again, and haven't raised my heart rate above 100 bpm in probably 2 years.

  • China 2008-03-05 02:36
    Good people can't always produce good code: as thedailywtf articles repeatedly show, there are many ways to impede good development. I think that the benefit and challenge of Agile is in removing as many of the impedences as possible while keeping the project focused.

  • Jim Bolley, PMP 2008-03-13 16:01
    Agile has a Project Management Plan. They just don't want to write it down.

    Agile has a Commumication Plan. They just don't want to write it down.

    Agile has an HR Management Plan. They just don't want to write it down.

    Agile has a Time Management Plan (Schedule). They just don't want to write it down.

    Agile has a Scope Management Plan. (although different). They just don't want to write it down.

    Agile has a Budget (Cost) Management Plan. They just don't want to write it down.

    Do you get my drift? What is the common thread? Although they don't want to admit it, they do everything a Project Manager should do, they just don't want to write it down.
  • Alex Glaros 2008-05-27 03:42
    I've been using a form of software development that I've learned on my own in the 1990's, that has some features similar to Agile. Can you please review it to see if it addresses some of Agile’s criticisms?

    Thanks,

    Alex Glaros
  • Alex Glaros 2008-05-27 09:04
    I've been using a form of software development that I've learned on my own in the 1990's, that has some features similar to Agile. Can you please review it to see if it addresses some of Agile’s criticisms?

    Here’s the link: http://gov-ideas.com/enterprise_focused_development.htm

    Thanks,

    Alex Glaros
  • ELIZA 2008-06-25 01:18
    opensorcerer:
    I might buy into this analogy, if you were talking about building a pyramid on a former swamp that had been partially drained, in the middle of a continuous 7.5 earthquake. Because I don't know what kind of solidity your requirements and environment have, but that's approximately how mine are. Let's also throw in a request from the Pharaoh for a cubical tomb mid-project, because the market research says cubes are going places now and we can't afford to become #2.


    It does occur to you that that would be specifying something that is apparently unachievable with the technology in question (ie, unmortared stone)
  • Brill Pappin 2008-07-05 04:58
    No, JamesKilton is correct.

    It does work, but what he's saying (and I agree with) is that it's "a state of mind" or rather a *way* of thinking about and implementing the software you are tasked with.

    Like most of us I've used several "methodologies" and as much "hacking" as anyone. but taken as a concept on how to write good code, Agile can help. The key however is getting the *point* of it rather than following some "agile bible" and that takes good people.

    However, inexperienced people can improve if they have good people around to follow (true of anything and any method) and can do it quickly using agile ideas.

    So far, I've been at many companies who claim they are "agile" but are no where close (somebody mentioned that sort of thing earlier) and in all cases it was because they just didn't get it... notice that I didn't say they were not good developers, just that they didn't get Agile; for those people and for those in this forum who don't get it (no shame on you), there is little point in trying to force yourself into the cold-press to conform... what your doing might be working for you, so keep your customers happy and keep doing it.

    However, this is really all useless bunk anyway if we remember that most of the cost of a product is maintenance, the argument is only about ~20% of the cost.

    We that understand Agile, will use *it* to keep our customers happy, as you will your own system.
  • Emily 2008-10-25 19:49
    This is single handedly the worst methodology I've ever come across in all 10 years in IT consulting - especially on the large projects. Because where there are large projects, there are politics (I don't make the rules). This model acutally presumes it it can eliminate politics to produce results - and it does quite the opposite. Agile probably would works well for start-ups, but where there are large projects, there will be politics. This is a natural manifestation when there is a combination of expectation and dependence within a project. I work on an Agile project for a Fourtune 100 company, and will be leaving the project and possibly my job because of this crap practice. Just a trash fad which has made me hate going into work every day.
  • Mr Anderson 2008-11-18 15:42
    Agile is an often mis-applied methodology, and it seems everyone wants to bash it because it doesn't work. It does work, but it's rarely done properly.

    It's not easy, and it's not a panacea. It doesn't preach 'no documentation' or delivery without planning. On documentation, it recommends that you produce enough (but no more). Same with planning. The key word is enough. If you don't have enough, you fail. You fail not because you chose a bad methodology, but because you took a simple methodology, cherry picked the easy bits and ignored the difficult parts.

    Agile is simple, but not easy.

    A better analogy might be power tools. An electric jig saw might make cutting easier, but if you're a crap carpenter it just means you screw up quicker (or lose more fingers).
  • Mark 2009-02-25 16:21
    I wonder if you've become a Scrum master yet? I enjoy reading these types of articles. Damon Poole at Accurev was a Waterfallian as well and is now an Agile proponent. You should have a chat with that guy.

    http://www.accurev.com

    ~M
  • Rick 2009-04-30 19:23
    >>Andy Wong said:
    Reply Quote

    Agile is good for understanding requirements and assist the customers to understand their own requirements

    The above is not true at all! On eof the principle of Agile is to make the story requirements vague and ambiguos so that open to the discusions.
  • ������ʳ 2009-07-23 13:51
    ��������<a href=http://www.redbaby.com.cn/diet/index.html>������ʳ</a>�����ν�����ʳ����ҵ������ʳ�ȵȡ�Ȼ��������ʳ��������ʳ�ճ���������˵�ġ�������ʳ��������ָ��ҵ������ʳ���Ͻ�ˮ���Ǻ���<a href=http://www.bondplus.net.cn>��ˮ</a>��ҵ�Ż���վ,�ṩ���Ͻ�ˮ���żҽ罺ˮ��������˽�ˮ����ɳ��ˮ,������ˮ,��ɽ��ˮ��ȫ����Ľ�ˮ��Ϣ��վ.�й�<a href=http://www.biocean.cc/>��ԭ����</a>�������ۺ��ԵĽ�ԭ������ҵ��վ,�����Խ�ԭ����ý�顢��ԭ���״��⡢��ԭ�����г��Ƚ�ԭ�������ºͽ�ԭ����������ȫ��������ݽ�ԭ���׷�,����԰��<a href=http://www.biocean.cc/>��ԭ���׷�</a>ˮ��,ȫ����ԭ���׷۾Ƶ��Ż�Ԥ������ԭ���׷���·,��ԭ���׷۳���ָ��,��ԭ���׷����϶����й�<a href=http://www.biocean.cc/>��ԭ������Ĥ</a>ý������Ϊ��ԭ������Ĥ��˾����ԭ������Ĥ��������ԭ������Ĥ��ҵ�����ҵ�ṩ���Ͻ�ԭ������Ĥ�����ṩ<a href=http://www.biocean.cc/>��ԭ������</a>��ƣ����ὺԭ��������Ʒ���й���ԭ�������������һ��Ѱ�ҽ�ԭ��������еĵط����ṩ���м�ֵ�Ľ�ԭ��������ƽ�ԭ������Ʒ��̳,<a href=http://www.biocean.cc/>��ԭ������Ʒ</a>�ɹ�,��ԭ������Ʒ�ͺ�,��ԭ������Ʒ����,���ԭ������Ʒ,��ԭ������Ʒ,��ԭ������Ʒ����,�󹺽�ԭ������Ʒ,�й���ԭ������Ʒ,��ԭ������Ʒ��Ϣ
    �ӽ���������,<a href=http://www.waitenwz.cn/>�ӽ�����</a>��վ����,�ӽ���������׬Ǯ,����ӽ����ش���,����ӽ����ع���ϵͳ,����ӽ����ع������
  • Me, myself and I 2009-08-21 08:30
    Nick Radov:
    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.

    You're right. But 80% at least of all code that's written is just interface code to database applications. What's so innovative about that? That's why I think it is only correct to assume agile methods are good only for a quite small part of the overall mass of software development projects - something you could call research. This is why I argue on using agile methods on a large scale - while they'll benefit research projects, they only decrease controllability and predictability for reinventing the wheel projects. And especially for projects of the latter type business aprpeciates predictability and controllability, especially at the cost of flexibility, and even at the cost of actual monetary cost.
  • LED display 2010-02-09 04:41
    <A HREF="http://www.ledtv.asia">LED display</A>
    <A HREF="http://www.ledtv.asia">LED Signs</A>
    <A HREF="http://www.ledtv.asia">LED Message display</A>
    <A HREF="http://www.ledtv.asia">LED Message Signs</A>
    <A HREF="http://www.ledtv.asia">LED board</A>
    <A HREF="http://www.ledtv.asia">LED curtain display</A>
    <A HREF="http://www.ledtv.asia">LED Soft curtain</A>
    <A HREF="http://www.ledtv.asia">LED soft display</A>
    <A HREF="http://www.ledsigns.cn">LED display</A>
    <A HREF="http://www.ledsigns.cn">LED Signs</A>
    <A HREF="http://www.ledsigns.cn">LED message display</A>
    <A HREF="http://www.ledsigns.cn">LED outdoor display</A>
    <A HREF="http://www.ledsigns.cn">LED fullcolor display</A>
    <A HREF="http://www.ledsigns.cn">LED board</A>
    <A HREF="http://www.ledsigns.cn">LED message signs</A>
    <A HREF="http://www.ledsigns.cn">LED panel</A>
  • LED display 2010-02-09 04:43
    <A HREF="http://www.ledtv.asia">LED display</A>
    <A HREF="http://www.ledtv.asia">LED Signs</A>
    <A HREF="http://www.ledtv.asia">LED Message display</A>
    <A HREF="http://www.ledtv.asia">LED Message Signs</A>
    <A HREF="http://www.ledtv.asia">LED board</A>
    <A HREF="http://www.ledtv.asia">LED curtain display</A>
    <A HREF="http://www.ledtv.asia">LED Soft curtain</A>
    <A HREF="http://www.ledtv.asia">LED soft display</A>
    <A HREF="http://www.ledsigns.cn">LED display</A>
    <A HREF="http://www.ledsigns.cn">LED Signs</A>
    <A HREF="http://www.ledsigns.cn">LED message display</A>
    <A HREF="http://www.ledsigns.cn">LED outdoor display</A>
    <A HREF="http://www.ledsigns.cn">LED fullcolor display</A>
    <A HREF="http://www.ledsigns.cn">LED board</A>
    <A HREF="http://www.ledsigns.cn">LED message signs</A>
    <A HREF="http://www.ledsigns.cn">LED panel</A>
  • greg 2010-02-16 18:08
    Coding priests should give up on agile and turn to improving stamina and spell damage.
  • Allan 2010-09-18 07:21
    Re "evolutionary" software: the one thing evolution has in it's favour is TIME - and LOTS of it!

    I believe you need to "bootstrap" evolution by having a fair degree of understanding of the customer's requirements early on (and by "fair degree of understanding" I do not necessarily mean 100%, but 80+).

    One can't keep on breaking down and re-starting (re-trying?) every time you find out something new from the customer.

    That's like evolution-by-failure: "something" will eventually result from all the retry-and-mishap-cycles... even if it takes a few million years...

    Ans that is what software development seems to be suffering from.
  • cindy 2010-12-18 09:28
    find for all kinds of watches and handbags

    http://replica038.com
  • John Quincy 2011-10-19 21:28
    If you haven't seen this video... it is very funny and yet so factual:

    http://www.youtube.com/watch?v=nvks70PD0Rs

    John
  • Mark 2012-03-18 00:06


    So you're saying most developers now are a bunch of sloppy H1 B's who can't write code, say isn't so ! I guess you get what you pay for !
  • Buck Ofama 2012-06-24 22:36
    "Good people can build good software, no matter what methodology they use."

    A+

    I was lately turned down for a Sr Jave dev role. Although the manager told the recruiter he wanted to hire me, later his dickhead weenie tech bully nixed it, ostensibly because I was "uncomfortable" with agile dev. Doesn't matter that the manager had previously told me they are working toward agility, but have a long way to go.
  • kim johnson 2013-11-20 12:34
    I was a developer for 10 years and hated process and management and people who didn't know anything running things.

    The next 20 years I was a QA Director and I Was the guy doing the stuff I hated back then.

    My conclusions after 30 years in the business and doing it both ways:

    Small internal projects can be done fast and well with really good people and little process. Sometimes it gets screwed up. But it's usually small, didn't do too much damage (hopefully), and can usually be fixed fast.

    But Murphy's law was created for Big Projects. Documentation (that useless stuff that tells you exactly what a system is supposed to do, how exactly it will be designed and tested) is GREAT (and cumbersome) on big complex stuff because everyone (painstakingly) knows what the hell they are doing and what to expect. And yes it takes MUCH MUCH longer and is a lot of paperwork.

    Theory 1: I think there is another reason for Agile: to get rid of dumb, bossy managers. Who needs them making everyone's life miserable, calling meetings all the time, tracking stuff they don't even understand, and they can't even code themselves because everything has changed and they only know stupid COBOL! OK. OK. Well get rid of them and see what happens. I heard stuff like, "its supposed to work that way! That's the way the code was written", or "the true documentation is the code!" (but a) who else can read code but the developer and b) what if it was coded incorrectly?)

    Theory 2: I think American culture consists of cowboys roping calves-rugged individualism stuff - "Look what I did!" Asian culture (e.g., Toyota)seems to me to be suited to working together closely as a GROUP. So we Americans have to, (for God's sake!,) change our mindsets, I think, to work in a group setting. That's why things seem to creep back to non Agile all the time, in my opinion, and why there is so much resistance to Agile. Should we go against our DNA? -or find ways to work with it instead? (Personally I'd rather row my boat downstream as opposed to upstream).

    What I think is good about Agile:
    - a POD-like space for collaboration and easy access to people BUT
    - cubicles to do your quiet, hard thinking stuff (And be an individual too who can make a personal phone call in private).
    - coming up with test cases during requirements and having the staff to do it (e.g., start an Acceptance Test document and get the code written to these test cases so it doesn't kick out at the end)
    - automating early if you can (but it took us 10X longer to write automated test scripts compared to manual, and sometimes you couldn't even do it at all! Our automation (with 2 of 7 testers DEDICATED to it full time) was completed after the release went out and was just used for future release regression testing, mostly.

    What I think is needed for Agile to work-
    -exact requirements
    -exact test case documents
    -test EVERYTHING built,
    -no late deliveries of code since it could break a lot of stuff already tested
    -and after the last code is written test it again for anything even possibly suspected of being broken by a change.

    Well, this goes against most of Agile!

    WHY do I suggest this? Because users of software hate bugs-it screws them up royally- clobbers their files sometimes, stops them dead sometimes, requires them to get on the phone to figure out what to do. They also hate stuff that takes a long time to deliver, too. But I've seen more user infuriation and rework with bugs. We had to work around the clock looking for workarounds, finding and fixing bugs, and praying the fix didn't break something else. Who want's that? How do YOU like it if you download something and it blows up??

    WARNING: After putting detailed, long processes in place you get award meetings and plaques when the 1st couple releases finally go out flawlessly, then people don't see bugs anymore, then think you can cut down on the processes since we don't have bugs anymore!!, and go back to crap releases again with new management installed to get it out fast (like it should!), then turn on you and blame you when it reverts to buggy (You didn't test it!!). Advice here: don't bother unless you get great management commitment to quality and the process you decide on (whatever it is: Agile, WaterFall or Water-Agile-Fall) - put it into a Quality Policy signed by the President if possible, and put it on the main hallway wall. Get signoff on a documented process too by him or her.

    TIP: Management loves documented process so they have understanding of how things are done in their organization (and can modify something if they like): lots of brownie points for this!

    Good luck whatever you decide.