The “not that much testing” part of the quote basically means that Google Labs is *not at all* an example of Agile Software Development, but an example of cowboy coding. It is, in fact, what Agile Evangelists are battling.

Um, “FOSS” – sorry, thought this argument (your lable was about Agile

@Stu
Ok. So when you completely understand the requirements (i.e., can write a requirements document that totally reflects the end place) and no changes are required then Agile is not required.
I mean NO changes …
There are times for this – legislation implementation … and others …

Agile does not equal untested … Agile is all about delivering software that works – not broken, not a “pilot”, not “Phase 1″ – actual production code that works as required. That means it’s tested (as much as any other way of delivering working s/w … of course), it’s implemented professionally – in fact, it’s got all the facets of “production” … why wouldn’t it?

The latter is the one that makes me uncomfortable. But as Mike said, these small incremental changes don’t have to be untested. It would seem that they have issues, and presumably also have the ability to roll these back (by adjusting the load-balancing/geo-serving to exclude the new servers).

The danger is that you can become cavalier and test a lot less and get away with it most of the time. Like coding on the production system, you can do it and get away with it. Until you don’t…

The potential loss of any benchmark for what your service availability needs to be, and what it really is, would contribute to this but knowing Google I’d expect that they have this all in place.

@Mike “let’s look at outcomes delivered” and you triple factors – speed, quality, cost. But we’re all selling many of these beta offerings as ready now, cheap (or free) and high quality – I’m not arguing against these offerings, just calling for more articulation of the fact that there is a risk in using FOSS that, notwithstanding the issues we all have with MS security holes, is different from using the products of the incumbents

Anyway – we’re going round in circles here – all I’m saying is those of us evangelising should think about the real world situation of those we’re evangelising to…

Google isn’t forcing anyone to adopt solutions which are still a work in progress. They are providing the ability for people who choose to to opt-in to try them out and give feedback (via collecting statistics). They are clearly labelled as experimental to scare off your “less technically minded users”.

So, they get valuable feedback to help them decide which features will become core parts of the product. That’s (part of) agile development, and is a good thing, IMHO. Delivering quality software is an industry-wide issue and Agile development is a step in the right direction to address that.

“ad hoc” = not coherent solution(s) to incompletely defined problem.

Consistent with my earlier comment; if you don’t completely understand the problem and solution spaces and implemented anyway, you end up with an ad-hoc solution. It may well be useful in a limited kind of way and many users might be satisfied with the result.

There are many, many ways to arrive at an ad-hoc solution quickly.

However, a useful software development method would be one that strove to produce software in the production domain more quickly and/or predictably than existing techniques.

I’m not interested in arguing quality without knowing if that’s a factor in a users project and the environment they are playing in. Quality is a factor in “scope” and therefore may be variable if the other two (time and budget) are fixed. Where is your “stable and robust” if the user wants something, (almost) ANYTHING for $100 by Wednesday … and if you say that never happens then I’d question where you’ve been working

As for GMail … I think that they have fixed (if woolly) scope, variable time and probably (I don’t know) fixed budget. That is, get it out sometime, on GMail that solves a user pain but don’t spend more than $x on it.

@Stu
Define “production” – does it include all of the millions of “one-offs” built within Excel and Access that are satisfying immediate business needs or only limited to something that comes out of the IT unit?