Follow Slashdot stories on Twitter


Forgot your password?

Comment Re:Agile means you always hit final release date (Score 1) 597

What is the difference to actual development between "we have a launchable product after each sprint" versus "we launch our product after each sprint"? There are obvious differences to the users, but what makes the former superior to the latter when it comes to meeting the overall project goals?

Also, there are a lot of non-agile alternatives, many of which do (or can) incorporate periodic release-candidate checkpoints. It is simply not accurate to talk about "the" non-agile alternative.

While no process will reliably produce good software with a dysfunctional team, Agile seems to be much more sensitive to dysfunction than many other processes. If you have a team full of disciplined, skillful individuals led with integrity by focused managers, many well-documented software processes will let you deliver good software on schedule. In the real world, teams often fall short of that ideal, so it is important for a development method to be somewhat robust to imperfect use, but Agile seems to encourage frequent distractions and excessive back-and-forth.

Comment Re:Agile isn't what I hoped it would be. (Score 2) 597

Funnily enough, most (academic) software engineering researchers understand that "waterfall" was originally intended as an exaggerated -- strawman -- description of a methodology that nobody uses in practice. Most practitioners also understand that any non-trivial project involves some backtracking, and most involve some iteration on parts of the development lifecycle, and thus don't try to use a strict waterfall method. Most Agilistas didn't get either memo.

Comment Re:Simple answers. (Score 1) 597

Your outline of running a software project applies equally well to a spiral method or a CMMI-compliant method or a lot of ad hoc methods without using any defined process. The practical problems with Agile are in the details that you glossed over that distinguish Agile from those alternative methods. Those other methods are not always better than Agile, but Agile is not always better -- and is frequently worse -- than them.

Comment Re:Developers hate Agile too (Score 2) 597

One of the hardest things for process designers to do is to fit their processes to the people who will use them.

Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up being a poor fit so often.

When projects inevitably fail in those circumstances, it is just annoying human behavior that makes the Agilistas claim the failure is due to not doing Agile hard enough rather than doing Agile in the first place, and that's one of the biggest reasons that Agilistas end up being obnoxious blowhards so often.

Comment Re:Agile is not a golden bullet (Score 3, Insightful) 597

Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.

Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.

Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.

Comment Re:I tell them I feel the same way! (Score 5, Insightful) 597

If you're not doing Xtreme Agile, you're not doing Agile right.

Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.

Comment Re:Incorrect Headline (Score 2) 210

You don't even have to get that far, you just have to minimally comprehend the bit that the blurb quotes from the article: "Emissions from drilling, including fracking, and leaks from transmission pipes totaled 225 million metric tons of carbon-dioxide equivalents during 2011, second only to power plants".

Comment Re:Pay the $3.99 (Score 2) 371

He was already in violation; he did not include either the source code or a written offer to provide source code with his binary version. If the binary version was accompanied by the source code, that would have ended his obligations; if it was accompanied by a written offer to provide source code, that would allow anyone to ask for the source code.

Slashdot Top Deals

The trouble with opportunity is that it always comes disguised as hard work. -- Herbert V. Prochnow