By Martin Millmore on June 21, 2007 3:41 PM
I recently got sent a message by the implementation team at Network Rail (the organization who run all of the railway infrastructure in the UK) to say that they have just completed implementing iRecruitment with a Network Rail specific skin. You can access their site at http://www.networkrail.co.uk/, and then drill down through the Careers link if you want to have a look.
They have changed the banners and navigation at the top and bottom of the screen to match the rest of their site, and changed the fonts and colour schemes to match the rest of the site. It looks almost seamless to me, and I think that they have done a great job. Well done guys, and thanks for letting me know about it.
Has anyone else used skins to change the appearance of their site? It would be great to see some more examples.
By Martin Millmore on June 22, 2007 7:09 PM
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]
