Podcast interview with:
Martin Nally, CTO of IBM Rational
Murray Cantor, IBM Distinguished Engineer and member of the Rational CTO Council
Part 2 of 3

SCOTT LANINGHAM:	This is a developerWorks interviews podcast recorded on June 6, 2006 at the Rational Software
Development Conference in Orlando, Florida.  I'm Scott Laningham, developerWorks podcast editor, and I'm joined on the
question asking side by developerWorks editor in chief, Michael O'Connell.

This conversation continues a chat we were having with IBM Distinguished Engineer, Murray Cantor and Lee Nackman, Vice
President of Product Development and customer support for IBM Rational.

Lee had another appointment and had to leave, so Martin Nally, the CTO of IBM Rational Software, joined us for the
second half of this interview.

Martin Nally, we appreciate you joining us for a few moments, thanks for your time.
MARTIN NALLY:	Thanks for having me.

SCOTT LANINGHAM:	Now, Murray, were you in the middle of a thought that you remember that you wanted to continue,
or...?

CANTOR:	Yes, what I was talking about is that even the most junior developer needs to know what code they're working on,
what decisions they're expected to make, what they're held accountable for.

And that, in fact, good architectures really help set that up for people.  And then if there's a problem with that code,
they need to know who to go to for that.  And so the idea was that governance isn't something that just affects
corporate managerial things; it really does affect the life of the developer.

And as we have talked about, doing it well empowers the developer, makes them more comfortable and provides clarity in
what they're working on and provides clarity to others on what others are working on.

And this is maybe the one new thought as we're sort of rambling on here, which facilitates communication.  So governance
actually properly done facilitates communications.

And one of the things that Danny spoke on yesterday --  I thought there were so many really strong ideas that I think
we're going to see are going to have all kinds of implications where to go in the future -- but one of those strong
ideas was about dealing with communities of interest and dealings across communities of interest.

So that's all about communications.  So if I know what I'm responsible for and you know what I'm responsible for, now we
know how that facilitates the right communications.

SCOTT LANINGHAM:	Do you want to chime in on this, or...?

MARTIN NALLY:	Yes, I completely agree with Murray on this.  You know, I'm an old programmer, right?  So that's my
background.  In fact, I'm still at heart an old programmer.

And it's sad to dwell on the negative things, but one way that you can really communicate to programmers about
governance is ask them about the things that didn't go well on previous projects.

So, as them, for example, who is it that gets to stay until five o'clock in the morning, you know, working late and
working weekends to try to catch up on slipped schedules?  And why did those schedules slip?

You know, most often it's because of either poor measurement during the overall development process, or, it's because of
late misunderstandings about requirements, functional or non functional and that cause a set of disconnects and people
scramble to try and catch up.

Also ask programmers about disappointments that they've had when . . .most developers are very passionate people,
they're very passionate about what they do.  And when they deliver stuff and it's not as well received by the intended
audience as they had hoped, it's an enormous disappointment.  You know, it's kind of a heart wrenching kind of
disappointment.

So developers in their own experiences, if they have any kind of experience at all, already have many experiences of the
consequences of governance.  They might not use the governance word; in fact, they might even have a little bit of a
negative reaction to the governance word.

But they're doing . . . they're the ones on the front line.  They're on the firing line.  They're the ones that get hurt
when the governance doesn't go well, and they're the ones that benefit when governance is improved.

So I think one of the things that you do is you find, you know, the right kind of experiences and relate it to the
experiences that developers have, and you can really reach developers and explain to them why governance is a
fundamental thing, but probably not with the same vocabulary that you would use to communicate to a project manager or
an executive.

SCOTT LANINGHAM:	Can I ask you both, I'm curious with this topic.  Is it a real new topic or at least is there a
newness to it because of its context within open development?  Or is this just a Rational message that has been there
for a long time and we're just hearing it from a different angle?

MARTIN NALLY:	So in many ways it's a Rational message that's been around for a long time, but there are some new
aspects to it.  So you know, we talked this morning in the keynote about open source and the fact that open source is
providing some really good state of the art examples of good process and good governance.

Open source also by its transparency and openness is providing some very visible examples that people can go and look
at.  And so those are some changes.

But I think we're also seeing changes from the business side.  There's more and more CIOs and CTOs, executives and
project managers, who are becoming more aware of these kind of issues and even attaching a label to something and
getting discussion and community around them, around these things, makes a difference.

And so people are, you know, and the higher level executives and project managers are thinking of this in terms of
transformations, changing process, improving process.  And, of course, one of the things, you know, why do we govern? 
So one of the reasons to govern is to improve process, as part of the measurement, part of the iterative process where
we continually improve.

So I think it's not a new Rational message, but I think we're bringing it into sharper focus, and I think there's also
some things happening in the industry that are causing . . . it's the right time for this message and this new interest
in it.

MURRAY CANTOR:	I think there are two trends, just to reinforce what Martin just said.  And one is that the interest in
compliance raised the issue about, if we're going to document decisions, maybe we should think about how those decisions
are getting made, which is try to keep people thinking about governance.

And the other is I think a trend we're seeing that really comes from one of the points Danny was making about forced
complexity -- that what we used to tell people is, only have small teams and keep them as isolated as you can because of
the dis-economies of scale and how hard it was to manage communications.

So our clients did that, and now you go into a bank and you might find 3,000 small applications that had gotten built
that now have to be integrated.  You can't just do that with small teams that don't need a lot of structure, now you've
got to think about how decisions get made and how things get done.

So Rational's always been about how to make teams work better together and create the environments and the like, but
this forced integration, forced complexity that service oriented architecture brings upon the world and tighter in
product development and just the need to deal with all that legacy migration that Danny talked about in the keynote, is
forcing governance considerations.

And you know, the point is, do you want to do this poorly, or do you want to do this well?  But you're going to have to
do it.  I think we see the two trends . . . the compliance thing is just sort of raised the issue, but in any case,
these things we've been talking about for years are being brought into focus now because of the technology trends and
the business trends that Martin brought up.

SCOTT LANINGHAM:	So many more impact points, so many more things.

MURRAY CANTOR:	Yes.  So I want to give you an example, to get back to the earlier thing about the developer, if we have
just a moment, because I did an assessment once, which was, it was so good, it sounds like it came out of a textbook but
it actually really happened.

What happened, this was a telecom equipment provider.  And they had built a small office switch based on an Intel
platform -- this is many years ago.  A small team of eight, nine people had done this thing as a prototype.

And the equipment provider thought that was great, let's make this a real product.  And they put 50 people on the team
with no decisions about governance at all.  And all progress came to a grinding halt.

And we came in to assess what was the problem, and what it turned out to be, every day, every developer came in and
traversed the whole organization to find out what people were working on and what they should do to add value, because
nobody owned anything.

And they were furious.  People were crying during the assessment, I mean, literally crying.  You talk about passion.  I
mean, I actually started bringing tissues to the meetings, to the things, because people were angry and they were crying
and they didn't know what would happen.  And the manager said, well, you know, you guys just work together, figure it
out.  And nobody had taken the leadership.

And so the answer was, well, create some architecture and create some ownership.  It was a governance . . . the lack of
governance was greatly impacting the developers in this case.

MARTIN NALLY:	You have to talk about governance, and you have to use the word “governance,” because governance is the
word that's in boardrooms, it's in the business press and so on and so forth.

But it would be really good if we could find a vocabulary that carried the same messages but in a vocabulary that would
appeal more directly to the technical community, because when I talk to developers I spend quite a lot of time at the
beginning trying to interpret this word, governance, for them. And sort of allay their fears and relate it to their
experience and to their work and to things that are relevant to their reward systems and so on.

And there is a great story here of the correspondences and why it exists.  But I think that we haven't really found the
kind of snappy phrases and the words that resonate with that audience yet.

SCOTT LANINGHAM:	And others that aren't worn out yet, you know, like it's not really “synergy” but you know, some
of those other words that talk about bringing things together in a harmonious way that have become tainted as well.

MARTIN NALLY:	The other thing, you know, Lee mentioned this in the keynote.  Many people who like me are old
programmers have been through experiences in the past that weren't terrifically positive around, and particularly, you
know, there was sort of a fashion in the eighties to take process standards that had been developed for manufacturing
and try to apply them in a straightforward way to the software industry. So we saw six sigma and ISO 9000, not that
these things aren't important, that's not my message here.  And the Malcolm Baldrige quality thing.

MURRAY CANTOR:	I lived through that, Martin.

MARTIN NALLY:	Right, yes.  So old guys like Murray and I went through this.  And it wasn't a very positive experience. 
What actually happened was that the development teams kept on doing what they were always, had always been doing, and
extra overhead and extra work was created in order to comply with these things.

So we kind of missed the point, right?  Instead of using it as a real opportunity for process improvement and to improve
the way that we did things, it was just a bunch of extra busy work that was required to get your ticky mark on these
kind of things.

And so many people of our generation or even 10 years younger than us have been through that kind of experience, and I
think some of the vocabulary around governance is bringing back these kind of echoes of negative experiences.

And again, that's not the reality.  That's not our messages and I don't think it has to be the reality.  But it takes a
lot of explanation at the moment to sort of retranslate that and to explain why the current focus on process automation
and governance and tools infrastructure is really trying to turn this, you know, turn this need into something that's a
positive for developers and all the practitioners as well as something that is required by management for accountability
and auditability.

MURRAY CANTOR:	This brings up another point, which is, you bring up the six sigma thing, Martin, and even way back then
I realized how the math was wrong.  That was the wrong mathematics coming out of manufacturing to apply to software. 
Although I didn't do anything with it at the time.

But one of the things that we've been working on with a set of us now with research and with some colleagues outside of
IBM even, is thinking about, okay, how do you reason about statistical process control and very disciplined process
improvement for the kinds of processes that get involved in development?

It's early days, but we're getting some ideas and we're not blindly applying things -- we're trying them out.  And so
far, you know, and again, if we do this well it will make everyone's lives better and more efficient and actually help
people add value.

And an example of this is I'm working with the estimation community, and what you find is the way we handle estimates in
development projects is really unsophisticated from the point of view of really how do you communicate the true
information and estimate, how much uncertainty is there, what is the source of that uncertainty and how are we going to
have the constructive conversation about addressing that as part of the decision process and a part of the ongoing
development process?

And you talk to the estimators and they're sort of beaten up the way developers are sometimes beaten up, because the
estimators are told, “you got the number wrong.”  Well, of course I got the number -- how could anybody get the number
right?

And is the source of getting the number wrong because I wasn't a good estimator or because we just didn't know enough?

But if you think some of the things you learn from process control is that, well, there can be both kinds of sources of
error, and you can control for one but you have to recognize the other, which is maybe you just don't know enough to do
a better estimate.  And that's something we should all understand so that we can figure out what it is we need to learn
to make better estimates.

So this is the other side of governance as well, which is, communicating the right information and good information and
then part of that is understanding that we deal with risky things.  And talk about those risks in a mature way, not
avoid them.

And this is, again, this creates a kind of, you know, it's all about really making  . . . the win/win is making the
business better and having the workers' lives be better, the engineers lives be better and all that, because it's all
part of one thing.

And if we do this, if we impose something stupidly or just inappropriately, you make things worse.  You add risk, you
make peoples' lives worse.  If you do it right, it makes peoples' lives better.

SCOTT LANINGHAM:	This developerWorks interviews podcast with Murray Cantor, Martin Nally and Michael O'Connell
continues in Part 3.

[END OF SEGMENT]