begin quoting Lan Barnes as of Fri, Dec 08, 2006 at 10:08:05AM -0800: > [snip] > Now for my "yeah but." > > I have always observed, going back to RAD, that these "new ideas" in > programming can be wonderful advances if followed with the proper > discipline. But all too often they become a fig leaf for programmers to > abandon or avoid discipline.
I've seen XP used for this. "Oh, we don't have to do that, we're doing XP!" is the cry.... and crap code results. (So far as I am concerned, they didn't _really_ do XP, but merely claimed to do so.) I've seen crap code come out of CMMI Level 3 *certified* projects, too, so I'm not that impressed with "documented process". I see the need for some of those elements -- analysis, design, documentation, comments, etc. are all good things -- but the overall 'methodology' seems just as abusable as RAD. Some pundit pointed out that with a good team, any process or meethodology will work, and with a bad team, no process will. > Programming is fun for programmers. Come to think of it, limited as I am > as a developer, it's still fun for me, too. Disciplined development -- > documentation, commenting (no, they're _not_ the same), proper unit > testing, task-driven development etc -- is not so fun. Programmers, > especially young ones, see these things as shackles on their creativity. Programming *should* be fun. Expecting the process of programming to suck is a good way to get crap code. But it should be fun in the same way that making pottery is fun -- it's a difficult[1] task that requires skill and can produce something that will give you a sense of accomplishment when done right. "Shackles on creativity"... well, I've never had anyone tell me that; if they did, I'd probably give 'em an earful. > Now if we take the venerable RAD system, we see much that is powerful and > good. Prototyping, customer involvement, eliciting requirements in a > real-world environment, and so on. But when it becomes an excuse for > slapdash, whoopee, undergrad-bull-session programming practices; _and_ (as <agreement> > happened all too often) when the prototype(s) become the core of the > development, or even worse, what is delivered; you will have an Shipping prototypes is a management failure, not a programmer failure. > undocumented, bug ridden system that had its requirements grow like Topsy > without any analysis. Yup. > I bet everyone on this list over 40 can cite a personal experience in > which that is exactly what happened. Not quite there yet, but yeah... > RAD. XP. Agile. Not much daylight between 'em. Depends on where you stand, I think. :) [1] The difficulty shouldn't be as a result of your choices for tools. Picking a poor tool to make a task more difficult than it needs to be is not a way to generate a sense of accomplishment. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
