• jmperso (unregistered) in reply to Randy
    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to _js_
    _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 (unregistered)

    What is this plan you speak of oO

  • itsMeAgain (unregistered) in reply to livid
    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 (unregistered) in reply to NotanEnglishMajor
    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 (unregistered)

    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. (unregistered)

    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.

  • (cs) in reply to superted
    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 (unregistered) in reply to F.M.

    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 (unregistered)

    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 (unregistered) in reply to 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.

    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 (unregistered)

    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 (unregistered) in reply to Anonymous
    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 (unregistered) in reply to Eeve
    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 (unregistered) in reply to J. B. Rainsberger

    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 (unregistered) in reply to Eeve
    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

  • (cs)

    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 (unregistered) in reply to poochner
    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.

  • (cs) in reply to Angel
    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 (unregistered)

    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

  • (cs) in reply to Nyuserre
    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.
  • (cs) in reply to F.M.
    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?

  • (cs) in reply to gwenhwyfaer
    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.

  • (cs) in reply to serge-nn
    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 (unregistered)

    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?

  • (cs) in reply to None
    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 (unregistered) in reply to chrismcb

    [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 (unregistered)

    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.

  • (cs) in reply to chrismcb
    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?

  • (cs) in reply to chrismcb
    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.
  • (cs) in reply to chrismcb
    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 (unregistered)

    Yes. You always think that when you hear of agile. I myself did. See Do you understand XP?

  • Robbie (unregistered) in reply to eatenbyagrue

    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 (unregistered) in reply to livid

    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 (unregistered) in reply to Robbie

    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 (unregistered) in reply to anne
    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 (unregistered) in reply to Zemyla

    "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 (unregistered)

    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.

  • (cs)

    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.

  • (cs) in reply to Jon W
    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.

  • (cs) in reply to bif
    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.

  • (cs) in reply to pirannia
    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 (unregistered)

    The analogy is ridiculous. You may as well have likened cars to badgers.

  • Tim Lesher (unregistered) in reply to Steve
    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.

  • (cs) in reply to real_aardvark
    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 (unregistered) in reply to Liberator

    --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 (unregistered) in reply to Anonymous

    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 (unregistered)

    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.

Leave a comment on “The Great Pyramid of Agile”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article