"I shared a vagrant optimism that some of us were making real progress, that we had taken an honest road, and that the best of us would inevitably make it over the top. At the same time, I shared a dark suspicion that the life we were leading was a lost cause, that we were all actors, kidding ourselves along on a senseless odyssey. It was the tension between these two poles - a restless idealism on one hand and a sense of impending doom on the other - that kept me going."
S Thompson - The rum diary
Publish or be damned is one of those scientific mantras you see sometimes, I believe it stems from needing to get your research out first before some other lab trumps you to it thus consigning you to an interesting foot note on the bibliography of a vegan honors students thesis.
Not a pleasant ending to a life's work.
In software development and testing especially it tends to be more publish and be damned. There is always a get out clause, a reason to not go live with something. In Agile there is this theory of producing potentially shippable code at the end of each sprint. What does that even mean?? I wouldn't be happy if I went to get my car from the mechanic and he told me I have potentially working brakes for example.
Now there are loads of places that will help define what "potentially shippable" is supposed to mean but I suspect that for most people it quickly translates into a BIG POTENTIALLY - and a very small shippable.
Is it shippable as soon as we fix that bug? or is it shippable as soon as we finish these five stories? Or more likely its shippable after an 8 week stabilization phase :-) so it was never potentially shippable at all.
That got me thinking, How would you change your work practices if your customer said to the team "You know what - I like this agile lark - Here are they keys to the live production environment and after every sprint review I want it in live within the hour!"
Can you imagine! A customer that put every sprints work directly into live!
I would probably react with total terror at first but then I started thinking about how the team and the process would change. I am willing to bet for a start that our velocity would half over night as various team members started thinking - "well I cant put that off, This is going live next week!". I would probably go on a one man uber crusade to automate every facet of the acceptance criteria before any of the code was written in case it came to me late and went live before I ever saw it!!
And then I thought "Why the hell am I not doing that now??"
I had a sudden image of a testers perfect world - Its a bad sprint, the developers are running late. Very little has made it through to be tested let alone marked as done and we have 5 stories in progress. Its 3 hours before sprint review and everything gets checked in all at once! - Normally that would be a nightmare scenario!!
[Scrum Master] "So what did we finish to demo?"
[Tester] "Did all the builds pass?"
[Scrum Master] "Yes"
[Tester] "Demo the lot! Its done!"