|Perl: the Markov chain saw|
RE (tilly) 3 (disaster): Java vs. Perl from the CBby tilly (Archbishop)
|on Nov 14, 2000 at 08:17 UTC||Need Help??|
You are asking the million dollar question.
For a sense of what you want to avoid, pick up the graphically titled Death March by Ed Yourden.
How common are these? Well a 1997 study found that 55% of projects were at least 50% over budget, 50% needed at least twice the estimated time, and 30% were delivered with under half the desired functionality. (I have heard stats like this before, but my reference this time is citing an article that does not appear to be online.) And that is counting by project. Considering that disasters tend to be larger than non-disasters, this understates your odds of being in one.
So how do you recognize a likely candidate? Well by a lot of things, but size is an excellent predictor. I don't know if they still do, but at one point Sun had an internal rule imposed by the CIO. Projects were limited to a maximum of 10 developers, a maximum of 1 year, and a maximum cost of $1,000,000. Any project exceeding those targets would be cut off because the risk of disaster was getting too great.
Note though that Perl does not miraculously solve this risk of disaster. In fact at least one monk I know of is currently in the middle of a death march. Instead what Perl does is aims to allow you to get as much done as possible within parameters for your team which are relatively low-risk.
One thing I need to make crystal clear. The risks that I am stating are for projects managed within the bounds of how most software projects are managed. There are ways to manage large software projects. IBM in particular has a series of projects which they decided ahead of time could not fail, which simply did not. I cannot track down the exact quote, but the person who was in charge of designing the AS/400 says that if development teams cared about quality they would not have all of the bugs. Well considering that the industry average uptime for an AS/400 is 99.9%, he may have a point. (When they went from 32 to 64-bit, your programs just ran a little slower the first time you ran them.)
Now about your last question. Well I am the wrong person to ask that of. I have no interest in worrying about my resume. Three years ago I was just beginning in computers. In two I get to leave New York City. In between I have a job I like programming Perl...