Agile again...?

On Tuesday I went to the combined UK SIG. If you read Andrew Clark's blog and then link through from his to Rob Baillie's blog, you might might be forgiven for thinking that only the three of us attended this SIG and agreed to all write about each other! Not so.

I go to these events pretty regularly in the UK, as I was "buddy" for the Modeling and Design SIG until the end of last year. These special interest groups focus on specific aspects of anything Oracle related and, as such, the UKOUG support a huge number. On Tuesday we had the second running of a combination of Tools, Modeling and Design and the Apps Server SIGs. This mix is quite fun, as I get to see a few talks in disciplines I typically don't get to see. I enjoy these events, because I get to talk to people who really use software and who praise and remonstrate in equal quantities. Feedback is key.

The highlight of my day was attending an Agile Programming talk. I was going to tell you at length about it, found and read Andrew's blog and to my delight, found the link to Rob's site and a write up of his talk. Do read it.

Briefly his talk was about Agile programming. Now the OO world and many Java developers love this, but the old timers (if you're about to stop reading, you might be one of them...) really don't go for this 'extreme programming...' I've heard the words 'cowboys' and programming thrown into the same sentences and sentiment. So here's the deal. Prove to me this works.. then tell me how you did it. Give me the facts... not the fantasy. ...and that's what he did.

Rob stood up and told us about his last 18 months and the very successful project they have been working on. His introduction was quite long, and went into detail about the project and his experiences. I got this from it. In 18 months, they never had a release fail. Think about that for a mo...

They had a demo environment and released regularly into this demo environment. If a user wanted a feature, this would be coded and released within days to that demo area. So the user had a response, and a tangible one at that. They also released into their production environment often. Did I mention they never had a release fail?

Surely these are proof points of a successful process.

He didn't mention what tools or products they used, or speak about the app itself. He didn't introduce the talk by explaining agile, or talk about the founder members ...blah blah... He didn't talk about the various points you have to do to be considered an agile project. He had 5 slides. Each slide had a sentence on it. Here are the points as I recall them:

• Understand version control
• The repository is truth
  
• An idiot must be able to run the upgrade (build) scripts
• Every developer gets a sand box
  
• Every sand box has a database

Understand version control: Basically, you don't need a tool, you need a process. It's made easier with a good tool, but without a process even the best tool is hopeless. Your developers and team must trust and use both the tool and process. One without the other is not enough.

The repository is truth: Well, any Oracle Designer user would agree with that. He didn't say that or even talk about what a repository might be, whether a database or file system. Basically his point here was: Can you rebuild your system from scratch if the live, production system disappears NOW. Do you have all the files, all the correct, latest files available to just rebuild again? He impressed on us again, that all members of the team needs to trust the repository, as the source of truth. Even if you are not in an agile environment, I wonder just how many teams in ANY development environment can point to their single point of truth for any version of their projects.

An idiot must be able to run your upgrade scripts: This was not said in a disparaging way. Here his point was that a complex script, requiring lots of input and control, which can only be run by a select few, will probably not be run very often. This resonated with me. When something is a little flaky, I tend not touch it if at all possible. "Leave it alone, it's working..." But if you have scripts that you run daily, you'll tune them and ensure they are fail proof. The more often, more people run these scripts, the more certain you are of their reliability. So each team member runs the upgrade scripts and they upgrade their demo environment regularly. So when it comes to upgrading the production environment, they knew it would work. (and it did ...another proof point!)

Every developer gets a sand box and every sand box has a database: The sand box is "my play area" and my play area must not affect anyone else and no-one must affect me. He impressed that the sandbox must have a database. He did mention that they used schemas and private synonyms, not a database per user.

In all this was a very refreshing talk, as I mentioned, the full document is on Rob's blog.

More on SQL Developer another day. Briefly, the room was packed and there are still loads of people who had not yet tested the product. I hope they have done so by now...