Developer Spotlight: Walker Royce

Walker Royce is the Vice President of IBM's Worldwide Rational Lab Services; he is also the author of <i>Software Project Management, A Unified Framework</i>. Builder AU caught up with him to talk about the process of software development and where we are heading as an industry.

Walker Royce is the Vice President of IBM's Worldwide Rational Lab Services, he is also the author of the book Software Project Management, A Unified Framework. Builder AU caught up with him to talk about the process of software development and where we are heading as an industry.

Builder AU: What are you here for in Australia?

Royce: Today we conducted discussions with CIOs and executives in Australia about how to get better governance. If you use the word governance with executives they view it as a positive thing, if you use the word governance with practitioners they view it as completely negative.

Our job at Rational, from a development perspective, is to provide painless governance. In other words, let's provide you with a development environment, automation and support for bookkeeping, traceability, instrumentation, metrics, progress reporting -- so that developers can spend more time designing, coding and testing and less time going to meetings.

That's the way we want to sell governance to developers, more freedom -- while selling it to their managers as better predictability. So extracting metrics and measures straight from the engineering artefacts rather than asking for progress reports.

I think that's one of Rational's biggest challenges, making governance a positive thing to practitioners, and the way we do that is by making the environment do all the work so that they get to do what they love to do. That's our job.

You are putting your tools into Eclipse, is there a point to having a proprietary IDE now?

I don't think so.

I think Rational and IBM's view is that we are going to use Eclipse as our kernel and build on top of it. The main reason is that it broadens the ecosystem of people who can contribute.

In fact, in my view, Apache and Eclipse have some of the best examples of good processes that there are. A real meritocracy on how people collaborate and produce quality products, the open software model is quite capable and we want to embrace that.

The open software processes are hear to stay, they've proven to be great ways to collaborate and we want to embrace them, build on them, and like Eclipse, build higher levels of capability that we charge money for and people find value in.

How important do you feel that the choice of technology is to a project?

If you are just a project manager, all you care about is this project, getting to the outcome, get out of my hair. You tend to take technology choices that are local optimised for the specific thing at hand as opposed to making a more global optimisation of a technology choice that in the long run is best for all 10 projects we are going to do, even though it may not be the best for one or two of them.

So I think that at a project level, technology choice is less important. At an organisation level, globally optimising your technology choices for scalability and growth is crucial.

It's probably one of the discriminators of most successful organisations.

What in software development today is really exciting you?

I guess what excites me the most is how important it is. I don't know of any product, any service or any system out there today where software isn't one of the most critical components.

Consequently, and this might seem a little odd, but the fact [is] that we are now demanding compliance to certain standards for our software processes. Most developers hate that but I think that they really have to take it as a compliment that they are now working in a discipline that is so important that we need to have real professional standards which have to be auditable, so that our stakeholders get more predictable results.

In a way it sounds weird to be excited by the fact that we need to embrace more auditable process compliance by our software teams, because that's not something that most people want; but in fact I think it is an admission of just how important we are. And if we take it that way, we can stomach it.

What do you mean by "stomach it"?

The point is not to pass an audit, the point is to have a great enough process that it easily passes the audit.

I think that along with our importance comes some responsibility to becoming more accountable and getting [products] out the door on time. That's a positive thing.

Along with any privilege comes responsibility that you may not like, but it's part of growing up and the software world is growing up.

Do you see any fads at the moment in software development?

So I see two competing processes fads, one is the "agilistas", the agile methods fans who believe, and I'm exaggerating but that's what a fad is, no process is better than some process.

Then there is the other side of that coin, which is the process zealots who believe that software is a simply a cookbook, here's the prescription go follow the prescription and you'll get the outcome.

And they are both wrong.

I think that any given project or organisation needs a mixture of those two things in a common sense balance to make them world. So the amount of process rigour you need is a fad on both ends of the spectrum.

A common failure pattern is using too much process and self-inflicting more than you need.

Do you get that a lot?

Absolutely, we get it with everybody. We get it internal at IBM. We self-inflict too much process on ourselves. That's just human nature.

I think that the Rational Process Method is perceived and accurately perceived to some degree as too process heavy because our standard usage model by our customers is to self-inflict too much usage rather than finding the minimum usage and grow it from there.

They start with too much and try to tailor it down. And really one of the reasons we published the Eclipse Process Framework was to try and work the other side of that and start with the minimum and just add what you need. We are taking steps to fix that perception and correct it -- but we'll be doing that for another 10 years.

Do you see the schism happening between developers that make the tools and those that use them?

Maybe, I don't see that happening for quite some time. But I do see the distinct line between development and maintenance going away.

In that, I think we are moving to a future of continuously evolving system -- and not here is the development phase, we release it to users and here is the maintenance phase.
A good example is eBay, Amazon or Google, they put out a new version of their product every night without the users ever knowing -- it's just a continuously evolving system.

If at some point their architecture gets so complex that they can't put out daily releases without becoming error prone, in other words their architecture starts degrading, then they're at risk of someone taking over their space.

But this concept of the continuously evolving system where you don't know what is maintenance and what is development, at least as a user, I think that's definitely a wave of the future.