- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Wait, people are still using "Goofus" and "Gallant" for analogies?
Most people got over Highlights many years ago.
Admin
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.
Admin
Wow. I am speechless.
Admin
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.
Admin
Amen!
Admin
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.
Admin
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.
Admin
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.
Admin
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
Admin
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?
Admin
A-freaking-men.
Admin
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.
Admin
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.
Admin
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! } }Admin
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:
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.
Admin
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.
Admin
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?
Admin
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.
Admin
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?
Admin
It isn't?
Admin
Let the religious methodology wars begin. . .
Admin
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!!!
Admin
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...
Admin
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.
Admin
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.
Admin
So say we all . . .
Admin
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.
Admin
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.
Admin
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.
Admin
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?
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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?
Admin
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).
Admin
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.
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.
Admin
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.
Admin
Admin
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...
Admin
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).
Admin
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%."
Admin
So Agile just work for small project team, in which must of the cases have too much process bureaucracy don't worth it.
Admin
Oh, gawd, the Agile bigots are at it again. In these discussions, we always seem to lose sight of three pieces of data:
untold thousands of systems have been successfully built with so-called waterfall approaches
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
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.
Admin
Ahem: http://en.wikipedia.org/wiki/Straw_man
Admin
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.
Admin
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.)
Admin
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
Admin
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.
Admin
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.
Admin
Sorry all, that chode was for jefrainmx
captcha: burned by lack of quote button