I was at the Deep Agile conference this past weekend and was able to convince embedded systems development guru Jack Ganssle to sit down for a brief interview. We only talked for a little over ten minutes, but we covered quite a bit of ground: embedded development, agile, agile embedded development, and even the joys of using a sextant. The transcript is below, or if you prefer to listen instead you can download the MP3 (11497.6K). The audio quality is less than perfect, but considering the hardware I used for recording and the lack of skill I have with the free software I used for post-production, I'm just happy it has any sound at all. :-)
Gregg: I want to pick up on a couple of themes from the interview you did with Nancy Van Schooenderwoert a couple of weeks ago and its something that James Grenning also brought up: Does Agile have a capital 'A' or a lower-case 'a'? My real question is: Does everybody get to have their own definition of what "agile" means and if so, what is yours?
Jack: It's a very difficult problem and nobody seems to know. Even in this very small conference I've seen agile used with both a capital 'A' and a little 'a'. As a noun and as an adjective. I very much view this as the Supreme Court viewed the definition of pornography: you know it when you see it, but it's awfully hard to define it. My take on agile is that agile has changed over the years. It used to be that there were very strict rules you had to follow. If you wanted to be an Extreme Programmer (XP) you had these twelve disciplines you had to employ. If you didn't use all of them you weren't doing XP. And I think the definition has evolved quite a bit.
Agile is more of a philosophy and you have to meld it to your particular development environment so that it fits what your individual needs are. My frustration with it is, in my experience, too many teams are using "agile" as an excuse to throw out all process. They're saying "hey, we're agile," which means, "we don't need any rules." When really agile is a very strict discipline. Now, it's different for you, it's different for me, but it is a process we employ.
One of the key things about most people's definition of agile is continuous test and integration. And your take on this is that test and integration are not distinct anymore, they are in the fabric of what we do everyday. But how do you do test and integration in an embedded environment where the hardware's not available yet?
I think that's a problem which is too often glossed over, and it is one of my frustrations. I think that the agile community gets it right with the idea of continuous test and integration, but they forget that with an embedded system, somebody has to be there watching the display and pressing the buttons.
And so the objective of running automatic tests, which is brilliant, is somewhere between difficult and impossible sometimes with the embedded world. I think the idea of stubbing stuff out to run tests is a great idea, but it's limited. We don't want to change our tests or our product in order to do testing. NASA says: "test what you fly, fly what you test; don't make them different."
On the other hand, I think there's some brilliant resources out there that haven't been mentioned here yet that people aren't using and they should. For example, you're from Austin! One of your companies down there is National Instruments, they sell LabView. I've seen companies in the embedded world using the LabView software, hooking it up to a video camera and watching displays with the video camera. The LabView software has some applications that will actually translate what it sees to ASCII. So you can watch maybe an LED display and it will read it, translate it to ASCII, and you can feed that back into your test computer, so you can actually see the results. And that is way cool.
One of the things you said you get out of coming to these conferences is the exchange of ideas. One thing I heard you mention that I thought was interesting was that you enjoy having your most cherished beliefs challenged by conference attendees. Is there a specific example of that? Is there an insight that occurred to you during a presentation, maybe as a result of a question or something that made you change one of your cherished beliefs?
Well, I'll tell you one that's been evolving in recent times, and I'm still struggling with it, and that's my beliefs on code inspection. I've always been a strong proponent of the Fagan approach to code inspections, because there's so much data that supports them. And the problem is Fagan doesn't work in too many teams. Teams are small. They have limited resources and sometimes it just isn't possible.
Some of the more agile approaches to inspections I think, even though it challenges my beliefs to say this, can be very effective. They have to be used, they have to be disciplined and all of that, but I think that that's one thing that I've been struggling with and I think that a lot of the agile community is
Given the need for inspections and all the other things that agile requires, you pointed out during your presentation yesterday that agile increases individual team member responsibility. Which leads me to a question that I ask all agile people: for a team to be successful using agile, do you have to have a team made up people from the far end of the bell curve? In other words, do you have to have more talented software developers to make agile work right?
According to the data, the answer is yes. There's a great book on this topic: Balancing Agility by Barry Boehm and somebody else. They actually looked at what makes agile work. And they've actually come up with five parameters that define whether or not an agile approach makes sense or maybe a plan driven approach makes sense. And one of those parameters is: really good people.
If you have less talented people the more plan driven approach tends to make more sense. I think people acknowledge this sometimes not very loudly. But I think people do acknowledge the fact that agile makes a lot more demands on people in terms of responsibilities and talents, and a number of other areas.
And of course, our people in this industry come from colleges and universities. You've been writing a bit lately in your newsletter about the state of computer science education at the university level. If you could wave a magic wand and change just one thing about the way computer science is taught at colleges and universities, what would it be?
I wouldn't let... well, before I answer that, I'm not saying: "Kids these days!" I think it was awful when I was in college - my frustration set hasn't improved. If I were going to do one thing, I wouldn't let anyone write programs until junior year of college.
I think what we do wrong in this industry is we say: "CS 101, first class, here's how printf works. Now go write some code." Instead of saying: "This is what software engineering is all about - and we're going to teach you how to build systems. And you know, programming is one of the tools you use to achieve that and we'll learn that later on." I think if we de-emphasize coding and reemphasize engineering, this industry would be greatly improved.
That takes me to my final question. We talk about the iron triangle of delivery: features, quality, and schedule. You've been in this industry a long time. My question is: Are we getting better at this? Are we getting worse? Are things the same? Is there any hope? What's better and what's worse?
I think we're doing better. You know, when I got into this field, I am a EE, and EE's learned nothing about software. We picked up assembly language programming because we had to. And we threw stuff together and we could get away with it because they were small applications.
Now we're building muti-million line applications. And you know what? They work! They're not perfect, but they work pretty darn well. And I think that's a real testament to how much better we're getting.
The thing that scares me a little bit is that the applications are growing faster than we're able to grapple with the issues we need to in order to build these sorts of systems. I think we are going to have to improve ourselves at a faster rate than we are. And there's actually some pretty good data on this.
As it turns out, embedded development is far better than the rest of the industry. Bug rates are way lower in the embedded world. And I think that we should all pat ourselves on the back for that, it's fantastic.
One final question: I've heard that you are a sailor. Is that correct?
You have your own boat?
Yeah, we have a 32 foot boat.
I just have to sort of imagine that your boat, unlike most sailboats, is loaded with all these really cool embedded gadgets! Is that the case?
We have a lot of electronics on board. All the usual stuff: radar, radios, single sideband, GPS, but you know something? I still carry a sextant and on every long distance voyage I take some sextant sights to stay in practice. And it's so much fun to figure your position by the sun and the stars.
My son who's 21 and quite the avid sailor is learning celestial navigation now. One of the things I enjoy is helping him appreciate this, because he's from the generation where everything is electronic.
Sometimes its more fun to do things the old fashioned way.
It is and we were actually sailing to Bermuda a few years ago and just for fun left all the electronics off. And we got within sight of the island, I used a sextant the whole way and I powered up the GPS and it gave me an answer that was off by 20 miles! I could see the island and it said I was somewhere else. The tools aren't foolproof.
Sometimes then, the old tools are the best tools.
Let's say: these things work together.
All right, we'll leave it at that. Thanks Jack.
Thanks, Gregg, it was a lot of fun.