timvw wrote:Hockey wrote:
If you don't have deadlines, your not properly setting your specs in the first phase of the SDLC. Yes Agile and XP advocate allowing feature creep or "change" but no where have I read that you should ignore deadlines. Rather the idea I got from it all was KISS. Keep problems small so estimating is accurate.
I more or less agree on this one.. What i've remembered most is the idea of 'having shorter iterations, communicating more, having all parties involved (input and feedback).. So that by the time your 'deadline' is there there is a good chance that atleast the 'core' features are there...
Last time i complained about an unrealistic deadline to a business person he simply told me to get more staff.. It didn't matter how much it would cost, he just wanted us to the job got done... because with multibillion contracts (energy sector) there is simply no 'mutual understanding' when you don't deliver in time...
Wow. You agree with me? I'm shocked and flattered. it's not often people see the method to my madness.
I figured when you said billion dollar budget you must have been working on a large gov't type contract. It's my understanding of hearing horror stories that in these situations it is best to hammer out most details off the hop and skip using Agile/XP, instead following a more traditional scholarly approach to software design; think NASA where mission criticality is impetus.
The reasons:
1) Deadlines are more important
2) Bottomless budgets (money is easy to spend when it's not yours)
3) High mission criticality;
Obviously NASA requires a bit more assurance than an Energy company might, but having a single system go down affecting a single business is certainly less worry than a major hydro plant failing and knocking out several thousands businesses.
I read a research paper a few years back on NASA software development. It was interesting, but the statistics were most impressive.
Don't quote me on the numbers but the difference is the point I am trying to make:
The comparison was Windows or Linux or similar.
Windows: Number of bugs / 1000 lines = 15
NASA: Number of bugs / 1000 lines = 0.0005
Like I said the stats were crazy. But the developers of that software have managed to produce a relatively solid source base. I think it said the bugs discovered were like one every 5 years or something.
You can't get that kind of accuracy following Agile/XP you need to follow a different methodology, more strict, set deadlines, specs, etc...
XP is really only for RAD scenarios where the dollar is the most important factor. Advocating good choices over quick hacks.
At least this is the impression I have been left with of Agile/XP.
p.s- this system. Is it written in PHP? Or java? I've actually consider applying at our local hydro company as I seen a job ad a while back. Think it could be neat.
Cheers
