Don’t get me wrong – agile development is a fantastic concept, but this post over on Mike’s blog got me thinking about things a bit.
His post related to the roll out of Gmail labs, in their release Google said that;
The idea behind Labs is that any engineer can go to lunch, come up with a cool idea, code it up, and ship it as a Labs feature. To tens of millions of users. No design reviews, no product analysis, and to be honest, not that much testing. Some of the Labs features will occasionally break.
Which is all well and good when we’re talking about such trivial things as different coloured highlights, games for email and other such offerings. But how about when we talk about critical services themselves?
A simple (ironically Google) search shows around 151000 results for Gmail malfunction. Some of these are from people who have had major data losses through using offerings created and rolled out while still in beta versions.
Don’t get me wrong – I’m a very early adopter that uses beta versions like they’re going out of fashion, but I’ve also seen the pain caused to less technically minded users through being forced to adopt solutions which are still a work in progress (I would mention Ubuntu but Mike would likely crucify me, if not him then many other FOSS folks out there).
So yes, these solutions are fantastic, but alongside it’s adoption we need users to be truly appraised of the weaknesses and threats of using these solutions.
Over to you Mike…..
I really like the idea to go first with some kind of alpha version of a software to the public. I think user feedbacks should be the main driver of software evolution.
But what is wrong about the perception of an alpha version is that alpha is today synonym of bugs where it should be unfinished functional approach.
So I completely agree with you about warning people, but I would also say that even an alpha version should be a bug less version and that the alpha, beta, … and iterative versions are about functionalities and not quality.
You talk as if there is a destination to the development, a final product, a shipped piece of soft6ware and that’s it … really, what was this software you talk of because EVERYTHING I’ve ever used was usurped by a “better” version … Agile simply takes change and evolution as a reality and incorporates.
Oh, and there are bugs in IE7 … and that’s version SEVEN … really!?
Well, perfection is… well… perfection.
But you can still try to reach a certain level of quality before delivering it in an early version. Don’t get me wrong. I don’t talk about production quality level softwares in alpha but an alpha doesn’t mean something full of bug either. It means tries, it means challenging the vision of the developer with real users, real feedbacks.
Then I hope there is still something you try to achieve with your code. Not always a great sets of functionalities but sometimes simple add-ons, …
ie, perfection is a fantasy world that people delivering real measurable outcomes should forget about.
Agile is not loose.
Agile is all about delivering software that works – not broken, not a “pilot”, not “Phase 1” – actual production code that works as required.
I am assuming therefore that you are both (@Yves and @Ben) saying that “Agile” = “alpha/beta” used to prove a point and then Waterfall is used to deliver the “perfect production software”. If so, you do not understand Agile.
I deliver working software (when I enter the realm of software development).
@Mike – you said that;
Agile is all about delivering software that works – not broken, not a “pilot”, not “Phase 1″ – actual production code that works as required.
But how does this relate to Gmail labs which, by its own admission will sometime break things in Gmail?
So forget the arguments about agile vs waterfall vs some other moniker and lets look at stable and robust vs not
From a long long time ago.
Steve Jobs once asked his yogi “What do you think of speed? You know – doing things quickly.” His yogi just laughed.
If you can conceive of every possible influence on your software over lunch, then go ahead and build it and put it in production after testing.
If not, then you can still build it, but it ain’t production code.
@Ben
and lets look at stable and robust vs not … nope, let’s look at delivering outcomes or not.
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?
“production” = environment in which software operates according to within an accepted tolerance of specified parameters.
“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.
Ben,
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.
@Cary point taken – but I go back to my comments re Gmail still being in Beta and yet evangelised by many (myself included as being the way of the future). That’s fine until someone gets burnt. (just search for “gmail malfunction” and see the results)
@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…
I think a missing part of the picture is the ability for Google to deploy changes in small doses, even on a geographic basis. They can, and do, use this to test the market, performance, and even test features.
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.
@Ben
those of us evangelising should think about the real world situation of those we’re evangelising to… … that’s my point exactly.
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?
Oh – and I stumbled across this in my rss feeder this morning – just FYI really (*ahem*): http://agilesoftwaredevelopment.com/blog/artem/googleplex-2008
It already has been hinted at in some of the earlier comments, but please let me put it bluntly:
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.
@Ilja – I agree, I should’ve made it more clear in my own posting, thanks for pulling us up on that
Being agile != sloppy/undisciplined