Re: The Status of Agile Programming Among Perlmonks?

[locked_user sundialsvc4]

A bit of my personal opinion on these methodologies (since you asked):

Software development is a creation process.   “On the first day” there is formless void, and “on the seventh day” you are taking a nap.   Every single one of us starts with an empty source file, every time.   Eventually, we wind up with a set of files that contain a correct piece of computer software.

“Okay... so, how long will that take?”

And here, alas, you have a Hobson’s Choice.   You can either:

• Lie about it.
• Say:   “I don’t know.”

The only way that you can truthfully say how long it will take to develop a piece of software is to know in advance how many unforeseen, vexing, absolutely show-stopper bugs you will encounter, and to know how long it will take you to solve each one.   But if you did know that ... if you could possibly know that ... then you would not have an obstacle at all:   you would merely have a milestone be a millionaire sitting on the deck of your two hundred fifty-foot yacht in the Bahamas, thumbing through your yacht-catalog and thinking about buying another one.  Or three.   Or thirty.

What you can reasonably do, however, is to have a workable process in place:   designing the entire thing as best you can before you begin, doing the work in a planned sequence, and testing as you go along.   You strive to develop some plan so that all of you are not groping around in the dark, and so that if somebody gets stuck everybody knows about it.   Yes, there are established ways to manage creation projects ... but none of them are sexy, glamorous, silver bullets.   Nor are they tremendously linked to the particular business of creating computer software.

A “methodology,” quite necessarily, is to some degree built to be saleable.   Books, seminars, consulting engagements.   The promise that you know how to make a silk purse.   The implication that no one on the company’s existing team knows these things:   that they are all, well, screwing up somehow, and that you just happen to know how.   That notion is unfortunately quite palatable.   But it is based on simplifications that, I find, don’t necessarily measure up to objective scrutiny, at least not to the extent that their zealots proclaim.

I do make it my business to study new methodologies most closely, because, if there is a technique out there with any potential impact on my company’s bottom (line), I want to know about it.   I usually find myself plucking a few pieces of tasty fruit from every new tree, but sifting through a fair amount of hyperbole to do it.   I remain hopeful, but disappointed.

JM2CW.   HTH.

[JavaFan]

Every single one of us starts with an empty source file, every time.

Really? I work with tens of other Perl devs, in a code base that was rooted more than a dozen years ago. Most of my projects involve modifying a bunch of non-empty files.

The only way that you can truthfully say how long it will take to develop a piece of software is to know in advance how many unforeseen, vexing, absolutely show-stopper bugs you will encounter, and to know how long it will take you to solve each one. But if you did know that ... if you could possibly know that ... then you would not have an obstacle at all: you would merely have a milestone be a millionaire sitting on the deck of your two hundred fifty-foot yacht in the Bahamas, thumbing through your yacht-catalog and thinking about buying another one. Or three. Or thirty.

I find this a lot of crap. First of all, if you have some experience, you ought to be able to quickly give a reasonable estimate on how long something is going to take. Someone ask you "how long will it take to do X", and you should be able to at least say "hours", "about a day", "a few days", "about a week", "weeks", "months", "years", and not be too far off. If you can't, given the years of experience you claim to have, you just aren't a good programmer.

Having said that, the IT world has a bad reputation of projects going way over budget, never getting finished, be full of bugs, and being scrapped before ever going live. I think that's a sign of immaturity.