« Network Rail iRecruitment site skin | Main | iRecruitment anti-virus solutions »

Development methodology at Oracle

I'm not really a process person. I really like to just get stuck in and get on with things. The last thing that I want to do is to do documentation, and pre-documentation and pre-pre-documentation. I like to just try things out without wasting time before I get stuck in. At least that's the way I used to be, and some of the time that's the way that Oracle used to be. I came across this article today by Shae Allen called If Architects Had To Work Like Web Designers. Have a read. It's very funny, and it is an extreme but recognisable caricature of the way we sometimes found ourselves working. Not all of the time - we were typically pretty methodical, even in my team. But just sometimes, it was a bit like that.

A couple of years ago though, John Wookey decided that he wanted to stamp down on that, and introduce rigorous enforcement of best development practices, based on best industry practices. I even got involved in designing the standards myself, looking at our code review process. For that, much of our inspiration was taken from books like Peer Reviews in Software: A Practical Guide by Karl E. Wiegers and Winning with Software: An Executive Strategy by Watts S. Humphrey. We weren't the only team. There were over 20 other teams looking at other aspects of our development practices, and the best suggestions from all of us have been put in to practice in Oracle now. Most importantly of all though, the Oracle management team all bought in to the process. Without that, we would still be the architect described in Shae's article.

So, what's the result of this? My Core HR team is one of the first to work our way through the life-cycle of our new processes. It was a hard sell to the developers. The changes involved front loading a lot more work. More design steps, more reviews, more methodology. It has taken a lot longer for us to get to the code stage than we had in the past. But we have produced far better code for it, and it will spend far less time in testing have fewer iterations of re-testing issues found by QA than in the past, because we have beaten the bugs out of the code before it gets to that stage. It wasn't easy, but we are all now converts to our new processes.  Even me.

[Edit: Clarified reduced QA time needed. Thanks Paul]

Comments (3)

Paul:

Hi Martin,
Thanks for blogging on dev practices. Encourage you to do more and go deeper into day to day issues.

I would say however that IMHO, "spending far less time in testing" is a very dubious aspiration to have.

I don't believe I have ever seen a product or project that couldn't have benefited from more & better testing.

Martin Millmore:

Paul, that's a very good comment, and I can see how what I said makes it sound like a bad idea. I'll explain what I mean;

If you write bad code, when your QA engineers test and find bugs, you have to fix the bugs and send them a new version to test. They may find more bugs when they have those fixes, so it's more bug fixing and more testing. That takes an unpredictable amount of time, since you can't say for sure when all of the bugs will be out of the code.

If the code that goes to QA has fewer bugs in it in the first place, there are less iterations of fixing and re-testing. That's the time saved on testing. It doesn't mean that the product has less final testing, but that the QA engineers are able to verify that everything works sooner, because they have a higher quality system to start with.

I hope that explains the philosophy. I'm going to do an edit to the article to make that a little clearer.

Thanks

Martin

Paul:

Hi Martin,
Yes, now I totally agree! There is no doubt (as has been proven in manufacturing) that putting more emphasis on "quality by design" and aiming for "zero defect" production gives lowest total cost and highest product quality. Traditionally there has been an over-emphasis on "quality by inspection" (which is essentially what most software QA is).

Anything to reduce "quality by inspection" is good, since it represents pure cost/value loss, and actually does nothing at all to reduce the number of defects in the initial iteration going into QA [it can even make it HIGHER because everyone feels safe that QA will "catch it"!].

You've got me really interested now ... love to see you blog about some of the practices that you feel (or have proven) make the biggest difference.

Regards,
Paul

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About This Entry

This page contains a single entry from the blog posted on June 22, 2007 7:09 PM.

The previous post in this blog was Network Rail iRecruitment site skin.

The next post in this blog is iRecruitment anti-virus solutions.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type and Oracle