|
> Or at least not the bogeyman it's made out to be Well... why do you think it's made out to be the "bogeyman"? The reality is that people tried (and continued to try) to run software projects that way: state up-front everything you're going to do, and then do it! What could be simpler? Anybody who's ever tried to do that has run headlong into the reality that: they didn't know up-front all the things they were going to need to do. For a long time, people believed that this was just a matter of experience and perspective and, after a reasonable amount of practice, software developers would be able to not only recite each task ahead of time, not only predict how long each was going to take, but would be able to do so in orders of magnitude less time than the actual task would take. This view of software development imagines programming as mostly just typing without much more thought involved than, say, laying bricks. That this model, if accurate, could be automated away seems to escape the attention of the project managers who insist on managing software projects this way. If it were possible to specify software in such a way that it could be predicted and planned out the way "waterfall" demands, it could be automated to take humans out of the equation completely. (And the project managers themselves could be replaced with a spreadsheet). If you go back and read the original Agile manifesto, it was written by people who were trying to explain that software is inherently unpredictable or - more to the point - that the parts of software that you need humans to perform are the unpredictable parts. There's an old saying, though, that nobody ever went broke telling people what they wanted to hear, so a cottage industry of agile "consultants" who'd never tried to develop software themselves made fortunes telling upper management that software is, as they wished, completely predictable, and the only reason schedules slip is because they're not mistreating their programmers harshly enough. |