newt

You could argue that without a coherent design, your next iteration is going to be longer. I'd argue the reverse - but it depends on what you mean by "big upfront design"

Every program, TDD or not, needs to get a basic architectural outline in place early on - e.g. decide if you're building a web app or a desktop client, which framework you'll use to build it. Usually you have a good idea of a lot of other major pieces of that you want in your architecture - they're there in "best practices" such as SOLID, repository pattern, CQRS, MVVM, etc. TDDs encourages "spikes" that prove the concept with a vertical slice through all layers of the app.

In my opinion and experience, "Big, upfront design" is a 1980s-1990s idea that all details of the program, not just the outlines, can be designed once before coding commences. And it is a completely false idea. TDD and agile say that you're going to redesign anyway, so you may as well accommodate that. This is where TDD speeds things up. Change is not just adding things to a program, it involves redesign on existing parts.

But I agree that an ounce of data is better than a pound of theory in this case. And number are far better than anecdote. That's what the article is for, I guess we should be reading it.

I think that if you read the article linked, you'd find that the study didn't work that way. Any study that measures different things between experiment and control groups is not going to be sound.

Then it gets to the field, and whatever you didn't catch becomes a 3-alarm fire.

I've worked on TDD projects, and those are definitely are counted as bugs. Severity 1.

No, please, be the bigger man and go first. heh.

Agile can't generate insight from nothing, it's not a silver bullet. But at least if you have some unit tests around your cool new code, you know that you won't accidentally break it later.

"requirements for a (short) release cycle" is a good description for a scrum sprint backlog. Scrum or agile does not say that you can't have "Specs, designs, and dot releases" in some form if you need them.

IE9 will use GPU hardware acceleration http://blogs.msdn.com/b/ie/archive/2010/03/16/html5-hardware...

Those were the first 2 that I googled. I'm sure that some of them are not agile, most likely by default - e.g. the older Microsoft ones, before MS or anyone else discovered agile. But honestly, all you are doing is throwing out names of popular programs without any idea if they are agile or not, and then claiming success on the ones that no-body refutes.

After that behaviour, the burden of proof is on you - back each one up with references or go away.

It would be interesting if you found major projects that evaluated both agile and waterfall and still chose waterfall or deliberately changed to a less agile process, instead of the other way. Rather than just software written before the people involved knew what agile was.

I disagree. to get a scrum project (or any project) going, you do need to have a vague idea of what you want (e.g. I want a website to sell my widgets online) and a few features for the next iteration (.e.g. List all the widgets. Take an order by email).

Scrum just says that you can inspect, adapt and iterate over that process.

How much refactoring do you do? How big a team does this approach scale to?

meeting with the customer to figure out if they want an accounting system or a CMS

That's an exaggeration. You seen some vision of what broad need the software fills before you start, and an initial backlog of high-priority features to get you going.

That would be interesting. Scrum says that your team should get themselves an appropriate set of tools and processes for the task at hand, and iterate, then inspect and adapt.

For a mission-critical lives-on-the-line software system, I'd imagine that there would be a lot of simulation and testing before the production release. Do you see a problem with that?

the only way that it can not have multiple passes is if the program is thrown away after V1.0. Any successfully program will be maintained and extended.

It releases lots of energy proportional to the mass, yes, but one proton + one anti-proton annihilating at a time, it's a very small explosion. And they only had 38 anti-protons.

I believe that one of the the articles quotes one of the Physicists saying that it "wouldn't even warm up a cup of coffee"

Edit here you go:

Prof Rob Thompson, head of physics and astronomy at the University of Calgary, one of the 42 Alpha investigators, said: 'This is a major discovery. ... We've been able to trap about 38 atoms, which is an incredibly small amount, nothing like what we would need to power Star Trek's Starship Enterprise or even to heat a cup of coffee.'

It works Ok for me on Windows, and since it runs on Adobe AIR, apparently works on Mac OS X too.

I bundle them up using instapaper ( http://www.instapaper.com/ ) which the article does not mention, but which is excellent.

Silverlight is iterating quite quickly, but then they have WPF to build on.

Nah, there are guides for that.

I'd say that maximizing employment is not the only goal.

Outwitting other people gambling on the stockmarket is explicitly legal, expected even. Thieving from unguarded targets is not.