Tag Archives: Watson

In parts one and two of our chat with  software star Grady Booch, we discussed his magnum opus project  COMPUTING: The Human Experience, Innovation, the Computer History Museum and the possible changing brain structure of Millennials, among many other things.

In this, the final segment of our discussion with him, we look at software – and software architecture – in general, Grady’s relationship with it in particular, the troubles facing Google and Facebook, the web, and his views on the SOPA, PIPA and ACTA bills.

To view the full introduction to this multi-part interview with Grady: Click here: 

Grady Booch: Capital I Interview Series – Number 14

[This was a joint conversation between Grady, Michael and myself. I’ve italicised Michael’s questions to Ora so you are able to differentiate between us – though, I think it will become obvious as you read – lol!]

Grady, You are credited with the building, writing and architecting of so much technology;  of all of those things, what is it that you are most proud of?

There are three things.  The first one is very personal.  My godson – he would have been eight or nine at the time –  was given a task at his school to write about a hero, and he wrote about me.  That was pretty cool!  Everything else is details, but I’m really proud of that one.

On a technical basis, I’m pleased with the creation of the UML, not just because of the thing we created, but the whole idea and industry around it that being able to visualise and reason about software-intensive systems in this way is a good thing. So, I think we lifted the tide for a lot of folks.

I contributed to the notion of architecture and looking at it from multiple views, and how to represent it.  I feel good about the whole thing around modelling and architecture and abstraction.  I think I helped people and I feel good about that.

UML was certainly a game changer.  I remember when it came in, before you got bought up by IBM.  It was like a wave going across the globe.  It made a profound difference.

And it’s different now because it’s part of the oxygen.  Not everybody is using it, that’s okay – not everybody is using C++ or Java and that’s fine – but I think we changed the way people think.

Our estimates are that UML has a penetration of somewhere around 15 to 20 percent of the marketplace.  That’s a nice number.  We’ve changed the way people build things.

Absolutely, especially at the big end of the market.

Yeah.  I wrote an article in my architecture column, that tells the story of when I was dealing with my aneurysm.  I was laying in a CT scan machine in the Mayo Clinic, looking up and saying: “My gosh, I know the people who wrote the software for this, and they’ve used my methods.”  That’s a very humbling concept.

It’s a pretty much a pretty good Acid test, isn’t it.

Yes, it is.

And your work is continuing in architecture…

Correct. I continue on with the handbook of software architecture, and a lot of what I do, in both the research side and with customers, is to help them in the transformation of their architectures.

For IBM the last nine months or so I’ve been working with the Watson team – the Jeopardy playing game – and helping the teams that are commercialising their technology.

How do you take this two-million line code base, built by 25 men and women, drop it in another domain and give it to a set of people who know nothing about that system.  This is exactly the kind of stuff that I do for customers, and I’ve been helping IBM in that regard.

That would be very challenging.  You’d need somebody with your brain power to actually manage that, I imagine.

Well, it’s not an issue of brain power, it’s an issue of: how does one look at systems like this and reason about them in a meaningful way.  And after the UML comes in – because it allows us to visualise it and the whole notion of architecture as used from multiple dimensions – all these things come together.  That make a two million line code base understandable to the point where I can know where the load-bearing walls are and I can manipulate them.

That is pretty impressive!  You’ve found a way of managing the slicing and dicing of the codebase.

That’s a problem that every organisation faces.  I have an article that talks about the challenges Facebook is going to have.  Because they…. every software-intensive system is a legacy system.  The moment I write a line of code, it becomes part of my legacy…

Especially if you’re successful upfront and gets massive growth, like they did.

Yes, and having large piles of money in your revenue stream often masks the ills of your development process.

Absolutely.

Google’s faced that, Facebook is facing that.  They have about a million lines of [the programming language] PHP that drives the core Facebook.com system – which is really not a lot of code – still built on top of MySQL, and it’s grown and grown over time.

I think, as they split to develop across the coast – because they’re opening up a big office in New York City – that very activity changes the game.  No longer will all of the developers fit within one building, so the social dynamics change.

Ultimately, what fascinates me about the whole architecture side of it is that it is a problem that lies on the cusp of technology and society.  It’s a technical problem on the one hand – so there are days I’ll show up as an uber geek – and on the other hand, it’s a problem that’s intensely social in nature, so I’ll show up as a ‘Doctor Phil’.

To follow-up on one of Kim’s questions: if you look at the backlog of IT, I think every company of moderate size is still struggling to deliver on business demands. Do you think that architecture helps or, does it actually contributes to the problem?

Architecture can help in two ways.

I’ll give you one good example.  There is a company called OOCL (Orient Overseas Container Line) that I worked with some years ago to help them devise an architecture for their system that tracks containers and all these kind of things.  Their CEO had this brilliant notion: what would happen if we were to take this system and extract all of the domain-specific bits of it and then sell that platform?

By having a focused-upon architecture, they were able to devise a platform – this is a decade before Salesforce.com and these kind of things – and they could then go into a completely new business and dominate that side of the marketplace.   Here is an example where a focused-upon architecture has a real, material, strategic business implication.

The other thing focused-upon architecture offers is, it  is allows you to capture the institutional memory of a piece of software.  The code is the truth, but the code is not the whole truth.  So, in so far as we can retain the tribal memory of why things are the way they are, it helps you preserve the investment you made in building that software in the first place.

What sort of size company are you talking about?  It sounds like the telco space… large Tier 1 and  Tier 2 companies. 

It could be anybody that wants to dominate a particular business.  Salesforce.com built a platform in that space.  Look at Autostar as another example.  Autostar was an attempt by BMW, and others, to define a common architectural platform, hardware and software, for in-car electronics.  By virtue of having that focused-upon architecture, all of a sudden you have unified the marketplace and made the marketplace bigger, because now it’s a platform against which others can plug and play.

There is a similar effort  with MARSSA, which is an attempt to develop a common architectural platform for electronics for boats and yachts.  Again, it eliminates the competition of the marketplace by having a set of standards against which, people can play well together.  In the end, you’ve made the marketplace bigger because it’s now more stable.

I agree. Also, an architectural approach separates the data from an application specific way of looking at things.

It used to be the case that we’d have fierce discussions about operating systems.  Operating systems are part of the plumbing; I don’t care about them that much anymore.  But, what I do care about is the level of plumbing above that.

My observations of what’s happening is that you see domain-specific architectures popping up that provide islands against which people can build things.  Amazon is a good example of such a platform.  Facebook could become that, if they figure out how to do it right – but they haven’t gotten there yet.  I think that’s one of the weaknesses and blind spots Facebook has.

I also think that they are, to a certain extent, a first generation.  I think the web, in terms of connectivity, is not being utilised to its fullest potential.  I don’t see any reason why, for example, any form of smart device shouldn’t be viewed as being a data source that should be able to plug in to these architectures.

Exactly!

Would that be an example of a collaborative development environment?

Well, that’s a different beast altogether.

With regards to collaborative development environments, what led me to interest in that space is emphasising the social side of architecture.  Alan Brown [IBM engineer and rational expert] and I wrote a paper on collaborative environments  almost ten years ago, so it was kind of ahead of its time.

The reason my thinking was in that space was extrapolating the problem of large-scale software development, as we’re becoming more and more distributed, to just how does one attend to the social problems therein.  If I can’t fit everybody in the same room, which is ideal, then what are the kinds of things that I do that can help me build systems.

I’ve observed two things that are fundamental to crack to make this successful.  The first is the notion of trust: in so far as I can work well with someone, it’s because I trust them.  You, Kim, trust your husband Michael, and therefore there is this unspoken language between the two of you that allows you to do things that no other two people can do together.

Now, move that up to a development team, where you work and labour together in a room, where you understand one another well.  The problem comes – like with Facebook, and what we’ve done in outsourcing – when you break apart your teams (for financial reasons) across the country or across the world.  Then, all of a sudden, you’ve changed the normal mechanisms we have for building trust.   Then the question on the table is: what can one do to provide mechanisms to provide building of trust?  That’s what drives a lot of ideas in collaborative development environments.

The other thing is the importance of serendipity – the opportunity to connect with people in ways that are unanticipated, this option of ‘just trying things out’.  You need to have that ability too.  The way we split teams across the world doesn’t encourage either trust or serendipity.  So, a lot of ideas regarding collaborative environments were simply: “What can we do to inject those two very human elements into this scheme?”

As we have been talking about trust, I’m curious as to your opinion on the SOPA, PIPA and ACTA bills.

I’ve Tweeted about it, and I’m pretty clear that I think those bills are so ill-structured as to be dangerous.

I get the concept, I understand the issues of privacy and the like, and I think something needs to be done here.  But I’m disturbed by both the process that got us there and the results.  Disturbed by the process in the sense that the people who created the bills seemed to actively ignore advice from the technical community, and were more interested in hearing the voices of those whose financial interest would be protected by such a bill.

The analogy I make would be as if all of a sudden you make roads illegal because people do illegal things in their cars.  It’s stupid the way the process that led up to this bill was set, I think, because it was very, very political.  From a technical perspective, while I respect what needs to be done here, the actual details of it are so wrong – they lead you to do things to the web that are very, very destructive indeed.  That’s why I’m strongly, strongly opposed to it. And I have to say that this is my personal opinion, not that of IBM, etc.

This is the final segment of our multi-part interview with Grady Booch. Part One can be read here, and Part Two can be read here. 

You can learn more about Grady via the COMPUTING: The Human Experience website, Grady’s blog and his Twitter feed. Be sure to keep your eye on the COMPUTING: The Human Experience YouTube channel where Grady’s lecture series will be posted.

[Kim, Michael and Grady Skyped from their homes in Sydney and Hawaii.]