Transcript

This is another episode, we're recording here at OOPSLA 2007 and we have a guest for this episode. So this is an interview and our guest is Dave Thomas. Welcome to the show, Dave!

Hi, my pleasure to be with you.

Great, thanks. So why don't you introduce yourself to our audience.

Okay, so this is Dave Thomas, the old country programmer, Eclipse Dave or Smalltalk Dave not Ruby Dave.

Right!

I really appreciate that, the other Dave Thomas writes such wonderful books because he does great brand maintenance. So I am the old one.

Right! You're among other things the founder of OTI, that's probably what you are maybe most known for.

Yes, I am probably most infamous for that.

So OTI stands for Object Technology International I guess --

Yes.

So, obviously you are quite a bit into object technology. So what do you think? What about the state of object technology these days?

Well, I mean its now 25 years from the introduction of sort of early commercial object technology and 40 years since Simula which is the original technology which shows you how long it takes for a good idea to get to the street, 20 years seems to be a common number or at least a generation.

That's maybe the point.

The generational thing, well also maturing of the technology and things like that. So I think object technology is still a very, very important paradigm and a way to provide modularity and to allow people put things together whoever I think due to the complexity of the current popular technologies and the lack of time, training, investment that often at least, particularly with the current technologies, objects are probably in the case of C# and Java in many cases. At least for businesses and some engineering organizations, creating a legacy that's probably as bad or worse than the previous technologies. But I think it's clearly a benefit and clearly it can work I think frameworks are a really bad idea.

Why?

I mean because basically frameworks are really hard to design, they are really a DSL, they are really a domain specific language encoded in an objects structure and language design in itself is very hard. The problem is that because you don't encapsulate the framework in terms of components, you get all sorts of accidental coupling and complexity where someone has to basically understand a lot more about the framework than they should to be able to use it as a component and there were so many excited essentially sort of frameworks are kind of have finished works in many cases but then they are intentionally so. So they are great when used by the framework experts but when you ship them out they become pretty difficult to use. Normal people shouldn't have to live inside a framework they should be able to just use it more like a component or a service.

So do you think this is -- that the problems come from the fact that you try to shoehorn something that should be a language into OO things that do you think building DSL's, I have to ask that. Building DSL's is kind of a more promising approach or is it inherent in the problems that there is a domain, you have to understand and it's inherently too hard to abstract the domain and built something that expresses the domain?

I think that framework design because it is effectively a kind of language design is hard. I think designing a good language is hard. At least it takes a different skill set then someone who is building applications and so I think object technology helps you but I also think that that some of languages is making it more difficult.I mean clearly the language like Ruby or Smalltalk, the distance between the DSL and the implementation is fairly short versus if you are doing another thing and you have to generate a lot more stuff and you've to understand the generated stuff because you can't debug it at the level of the abstraction, itself.

Right! My impression is that object technology is good for low level design like stuff but it's not an architectural paradigm because it's a different level of granularity and on the architectural level people talk more about components. What do you think about that -- I mean components were the next big thing after objects, did they fulfill the promises?

I think we got rushed in and we shipped frameworks and we didn't ship components.

Okay.

And I think that largely had to do with the economics. I think there was a great opportunity missed in that someone should have started the Intel of software components and built the components that were very robust and people have demonstrated in small ways I mean from TCP/IP stacks to widgets and things like that. That people will buy components, I think if people had actually invested in component engineering, the way they do for Silicon that we could have a lot better quality components but there was a belief that a lot more people could do this and so I think we kind of rushed out the technology and the frameworks. I don't think we understood how hard it was I mean the reality is that for a lot of people -- even an easy language like Smalltalk are still hard. The abstraction process and things like so --

And the difference between components and frameworks from your perspective is probably black box versus white or gray box, right?

Yes, I mean I think the reality is that everything is a gray box but you definitely, today is white box. So that's and the boundaries are not clear, so a clear interface. So I mean I think that the quality Eclipse process is something called API first which is essentially you define the architecture through a set of API's and these are concrete classes or they can be done with the special language thing like interfaces if you have it. They are really part of the architecture and then they are in there and they are versioned and they are very deep and they are really solid boundaries that people don't cross.

Do you think that SOA provides a right step in the right direction and maybe like formal contracts and decoupling, I am not talking about web services and that technology stuff, rather about the architectural style of SOA?

Does SOA have an architectural style?

Well that's what people say, I mean it's clearly something different from just using WSDL and SOAP there is more to it.

Maybe, I think by the time anybody gets anything built with the current SOA tooling that they will have been replaced by mashups using RESTful services. I just don't see all this complexity.

Over engineered --

Well and you can't tell when you should use, when should I be using BPEL4WS and when should I will be using Java. So if someone says well interface and service and separating implementation from, that's just I mean that's the whole principle we just talked about API first. So when someone says, well I am designing a service, well the whole point I guess if you -- If it causes you think about the fact that you are actually providing a service and think from an interface point of view then it's good. So that part I guess is good because it takes you away from this whole framework problem and it means that you think about distribution and decoupling and things like that. So I think that part is good but the problem is the hype and immaturity of the infrastructure, the complexity, the tools, the fact that it's another stack of vender middleware that you can't tell what it is doing. So I mean I think again the problem is that the vendors want to turn everything into a platform game by having everything on the platform because that means you have to buy from them versus buying from, for instance an EAI vendor who was doing the same thing quite successfully but they weren't getting the money.

Let's go back a little bit in time to your Smalltalk days. Well maybe today are still Smalltalk days I don't know. So what's the state of Smalltalk and why is Smalltalk, the best language ever designed maybe, I don't know?

Well, I think I mean, I certainly don't want to be the one operating the Smalltalk museum and Smalltalk is a wonderful technology. It's still a very useful technology there are many, many things that were wrong with Smalltalk. In some cases some of those have been actually fixed by Ruby. I think Ruby has some areas where it improves over Smalltalk. Smalltalk had the property that it was that, it let you get things done quite quickly. The programs were readable by people other than computer scientist.

I mean is that really true?

I have had business users and engineers Who basically said, "Well, this is the only useful thing I've seen since Fortran," and they could actually read their program because the keyworded syntax basically gave them a kind of DSL and sort of -- the classes so that they could get a DSL fairly quickly by appropriately naming, and they found that to be pretty friendly and useful. So it was a very good technology for doing that it had lots of problems as well and I certainly, I think it's always important I think how you could do better than how you, and who wants to go backwards in time.

Is one of the reasons that Smalltalk wasn't accepted in the mainstream the fact that maybe VM technology wasn't there yet in terms of performance scalability or was that not an issue?

No, its not an issue I mean Smalltalk VM performance was always very competitive and arguably it took years for the Java VM performance to even catch up. The reason that Smalltalk was eclipsed in the market was very simple

eclipsed wasn't intended to say Eclipsed.

No.

Okay.

No. I had something else there but I think I will pass. The basic reason was that those who were competing against Microsoft hoped that Java OS would actually give them a position in the client. So IBM and others were losing their position on the client and very concerned. So the decision for Java was really about Java OS not about programming applications in Java. It just happened that because the JVM -- JVM is more challenging to implement giant dynamic languages on and largely the Sun marketing message. So Java became a weed language which killed off all other languages as a side effect but there is -- I mean there were lots of ways to be able to implement and we are finally seeing now that people with JRuby and things like that are doing decent implementations and the machines are a lot faster too so, the issues of performance are not really so critical.

I think that's interesting trend today that it in the Java land there is this perceived separation between platform and language and people basically agree that the language is at the end of its time kind of and the platform isn't.

Yeah, well because so many people have bought it.

Sure, yeah.

And the vendors have no other platform and so they have to make it work but I think there's a lot of people who see in fact web services in some cases is an example of trying to move to something, that's above the level of the Java language.

Yeah, move away from language to protocols in some sense.

Right.

So, you have already mentioned Ruby. Do you think it's a worthy successor to Smalltalk? What are the commonalities? What makes it so nice in that context?

Well, I think Ruby has the characteristic that has the uniform object notion. So everything is an object, has a syntax that's a little more friendly than not as friendly as the Smalltalk syntax but it doesn't look like C all the time. So I think it's more readable when you embed another language in it, right. It has some nice concepts in terms of -- Ruby in particular has nice concepts in terms of mixins and things like that.

Metaprogramming --

Some modularities and things like that, that are interesting. Metaprogramming is a sort of mixed blessing because most people don't know when to use it.

Do you think it's overused --

No, I don't think it's overused in Ruby I think it can be dangerous when it leaks. I mean the kind of problem is that you know if you -- in Rails for example, I haven't looked at the recent implementations but it did a lot of metaprogramming and redefined a bunch of fairly key stuff that was in object which is fine if you are the implementor of Rails, the problem is if someone is going to read the code, they may assume that that's a pattern that they should use in their application code which would be inappropriate. We had that problem in Smalltalk and in many ways do.

It's also in C++. If you use Template metaprogramming to do some performance optimization within Boost, for example if people actually have to see it or see cryptic error messages that come from some compiler hick up then that's a spill out.

Yeah I think it's the fact that we don't make it clear when you cross the line and so you really like to know when you are doing reflective programming. You really like to write that code in different color or something like that. So people are clear that this is not something that you should do, scary code begins here or something like that.

I discussed with Erich Gamma this morning about some of similar same things and one thing we discussed was refactoring for dynamic languages. Is it true that, well Smalltalk had all objects in one big bucket in the -- how do you say this, in memory object space and the editing tools were in the same space. So if you as an IDE wanted to know what an object can do? You just asked the object by sending it a message, so it wasn't text analysis or any of that stuff, right?

No, no that's right, the nice thing is Smalltalk like most Lisp systems had an internal representation of the program at all times so you could actually look at it and in fact that's what the metaobject protocols let you do, you could actually look at yourself within some things we cheated on, so you really couldn't but it look like you could.

And Ruby doesn't have that. You don't have the IDE that has the objects live in memory. So I thought that was a big difference in how you would build a tooling for it?

Well I think one of the lessons from Smalltalk and certainly when we did embedded Smalltalk in cross development and certeinly built -- VAJava was built in Smalltalk. You realizes it's a good thing to separate your development environment in some sense from your execution environment because things can leak and so I think. For instance you can easily go along and create things on the fly in Smalltalk or what you can in JavaScript as well and if you save them you don't remember that you have actually created these objects. So there is no declarations for them, you are dependent on global stuff or things that came in and you just introduced because they're in your workspace. I think separation is nice but being able to play with your program. Dan Ingalls has just demonstrated that with his new Lively stuff as well to which --

What's that?

Sun's announced this thing called Lively which is open source and basically is implemented a lot of the Squeak stuff, object inspectors and the Morphic user interface and the --

For Ruby or what --?

No, for JavaScript.

Oh, Okay.

And it runs on a JavaScript VM plus SVG. So I think the workspace concept was certainly a big thing although an ENVY/Developer we did refactoring and we weren't in memory and those sorts of things but certainly that was one of the things, that makes it in some cases easier than just working on the text and I think that is one of the problems with IDE's and performance and a lot of the issues is because they don't work on -- they have to kind of reparse and do a lot of the stuff and so that makes the IDE's bloated and complicated because they have to redo that work all the time.

Yes, I was about to ask you about today's development tools. After all I mean just to do some history here you are the guy who facilitated, and probably shouldn't say invented but kind of made sure that Ellipse existed and maybe you can tell us a little bit about that background and then tell us about what you think about the tool environment these days.

Well, I mean, certainly Eclipse was built by an incredibly talented team of people and I had the privilege to work with them but the real issue is that IBM needed in order to get past the Sun fud because we implemented VisualAge for Java in Smalltalk. We realized that we had to have an IDE that was implemented in Java for marketing reasons if no other that we would not ever get the blessing of Sun. I don't know we couldn't get the Spinning CoffeeCup and it always do whatever. So we decided to implement, what became Eclipse.

And we, was at that time was OTI, wasn't that already IBM at that time?

No. A decision was made at, we were in IBM at that point but you have to understand that OTI, actually we ran as a separate company for seven years, was a wholly owned IBM's subsidiary but that decision was made of course in collaboration with IBM that this was the right thing to do and a lot of IBM people arguably -- 70% of the people who were actually involved with Eclipse were people from outside of OTI and IBMers who maybe came into the OTI kind of lab environment and it was done in a very compressed time scale, had to be done very quickly. We tried to provide -- the development team tried to provide a VisualAge Smalltalk like development experience because we -- our customers were used to having an interactive environment where they could compile and test things live and so on and. So in the beginning that wasn't so difficult but then between Java just after the first version of Java, nested classes and all that stuff was implemented and that meant all the incremental compilation is very, very hard because you can't just use local scopes. So dependency management inside the compiler and things like that, became much more challenging. So it evolved out of that and it's incredibly successful, thanks to a lot of people in the Smalltalk community and others who kind of embraced the idea and I think open sourcing certainly had a big help in that working with universities and so on. So today it's your legacy IDE, right.

So, you think it's too big, too much of a thing or I mean --

Yeah, I think it is. I mean I think it takes up too much space on your desktop. You have to put up with all these classes and the stuff, very complicated; very few people know how to use it proficiently. Part of that is just due to Java itself and the huge Java class libraries but I mean I think like anything else if you were building something new today I only think that only a fool would build something in the same way they did it the last time, you would benefit from the experience.

Yeah, sure. I think a lot of your arguments is about complexity versus simplicity. And in the bar recently we talked about I said something like if we now went back to Lisp people wouldn't like to do this because the language is like too simplistic and you then said well what's a limitation for some is, an enlightenment is something good for others. So do you think there needs to be a language that is small, that has more orthogonal concepts like Lisp or Smalltalk that lets us do more things with less complex initial building blocks?

So the short answer is very much. I think what we need to do is find those that the essence of good language design is trying to leave out more things and trying to make things more consistent. It's a very hard problem but I think to the extent that one, only has a few ways to do things and they behave consistently that means you can count on them and the higher level that language the fewer lines of code and in the end KLOCs kill. The more code you have, the more code you have to maintain, the more complicated it is, the harder it is to refactor. So anything that allows programs to be written quickly, changed quickly tends to lead to productivity and better quality in my experience.

So the real Lispers will say that there's nothing like Lisp and there will be nothing like Lisp. So do you think it is Lisp and it will be Lisp but what do you think, is there a language on the horizon or trends on the horizon where you see this kind of approach implemented?

Well, I mean there are lots of niche languages inside of companies. So I think if you have actually looked at what people are doing, they are trying to unify. So I think anyone who has used several of these languages will tell you that there's things that when they are in another language they really, really miss. So I mean people who only program in one language of course, they only play one instrument. So I can understand them -- their cognitive load of switching is hard but if you've talk to people who have used several different languages they can tell you "well this is great but if we had this other feature from this language this problem would be way simpler".

Scala seems to me to go in that direction a little bit. It has functional stuff. It has pattern matching from Lispy languages; it has type inference, still statically typed. So it looks to me quite promising.

I don't know Scala. I'm going go to the tutorial at ECOOP, because I couldn't make it here but I'm looking forward to, just spoke to Martin Odersky and hope that he can do it again at ECOOP. I think it's an interesting language. I think it's very complicated.

That's true. James Noble once called it the PL/1 of our times.

Well I guess it's cleaner than that but I think that the type systems are very, very complicated. So I think the ideal language in my perspective is a language which takes the best from Smalltalk, SETL, Scheme, and APL.

APL!

Yes

Okay --

Well because it turns out there are lots of things that the APL operations are very, very convenient and very efficient for both execution for expressing certain things but I am not arguing that I would take the APL syntax.

No well, sure.

But there are lots of cases were that's a very compact and efficient expression and appscript for example is a Smalltalk done for the Mac for scripting user interface classes which actually extends Smalltalk by defining something call a message pattern so that you can actually do APL style programming in a style like of Smalltalk. So I think there are some very interesting ideas if you can bring those languages together and there are people working on those sorts of things and certainly I think Haskell is a strong contribution but again I'm not a competent Haskell programmer I am, I'm a stateful sinner!

Dirty, as Erik Meijer would call it.

That's right, dirty. And Erik and I are comrade in arms and as long as we could -- (inaudible). He is a big fan now of duck typing and structural type of dynamic core, with a type system to help you. I see type systems in the broader sense like Gilad's pluggable types, a notion that a type system is really a constraints system you impose on things and in some sense invariants, all these things are constraints on your program which help your program, improve it's correctness and find bugs. So I think separating those issues that's something so you start, you can think easily and then you can start screwing things down and you say okay now I want you to check for this and check for that. I think we're getting closer to where we can start seeing things like that, that would help developers be productive.

Sometimes I think that the most important aspect of a parenthesis static type system is to allow tool support to have a nice IDE. So I mean if somehow that the -- I mean yes of course the compiler gives you warnings and errors but you can do this with testing and you should test anyway. So the IDE support I think is one of the really big deals in static typing.

My claim is that you need the IDE in these languages. I mean the reason they have to fill in this stuff is because you can't remember all the bloody APIs and everything else and the coercions and everything like that. In principle many people that use IntelliJ or Eclipse don't actually know how to write in those languages because the IDEs are doing more and more in terms of auto-completion, filling it in and so on.So I think part of the problem there is in fact that languages have all that complexity. So static typing has it's place. If you actually know what you're doing and you're doing it for the second or third time then you know what the types are. I tend to work on new applications and new products and most of the time we don't know what we're doing.

Yeah, it's in a sense exploratory.

Yeah, a lot of it is, you build three times and when you are building the third time probably you want to commit to the types and so on so. Again I think the difference is if you are in a fast, dynamic language you tend to do test first which gives you kind of the same thing, you get from the type system. So somehow I mean the experiences in the programming in dynamic languages is less reliable than programming in static languages, that's not borne out in fact. I think you just find the bugs in different ways.

So let's switch gears a little bit and talk about agile development, especially in the large. Do you think agile development scales I mean I know that for example the Eclipse folks, although they are distributed and they have these various teams. They use quite an agile process the Ellipse way. So any opinions on that?

Well, since I lived that life for many years and one of the things I do is do large scale lean and agile transitions. I am currently doing a thousand person company and another which is a 400 person company or division. I think the reality is that there are lean and agile approaches. I think the most of the things that are currently labeled agile really deal with individual team and the practices for that team. I mean they are wonderful but most of the things that you need in the large actually come from product manufacturing and a lot of those of course came from lean was, the OTI process used to be called Just In Time Software which was taken from Just In Time Manufacturing, from Toyota, as all the lean stuff was and I think that if you are going to build large products you need to follow product engineering practices and I think the difference between making agile success in the large is adding the other product engineering practices beyond what you do inside the development team. All the stuff that agile teams do -- the Scrums, the TDD and all those practices are great and they really do help those small teams but they are not enough if you are in a large organization, particularly a large product organization and in fact they are disruptive if you don't have a process for managing them overall because there is an illusion that somehow you can take a group of three or four wild and crazy agile teams and somehow they will just figure it out themselves and that in my experience is not the case.

Can you give us one or two or three examples of what such product management practices are, so I guess our listeners are not probably, not very familiar with these kinds of things, so any good examples?

Sure! So the kind of things that we do in our process, well in Eclipse you've probably heard of the something called the Endgame and so that's something, a release engineering would call that.

So polishing the thing at the end --

At the end ensuring all the pieces come together, all the dependencies are managed that the continuous build in matrix environment is all in place. So ensuring there is full transparency, recording a common database and putting a lot of infrastructure to put in place for serious large scale agile development. At the beginning we have two other activities. One which we call envisioning, which basically takes the concepts or the ideas from the customer or the marketplace whether there would be focus groups, house of quality, a set of techniques that are well pretty well known in the product engineering and product development world and produces essentially prototypes for tangible requirements and then we have a definition phase which really is a large scale architecture API first design, the planning two level. A two level estimation and work allocation approach, the deals with how you distribute work to teams, how they interact, separation of component teams from featured teams, how those things interact and that's something it's not typically that's not something -- you don't need that if you're not doing this large stuff.

And you don't find that in any of the agile literature community as necessarily?

No, I think that's true. I haven't seen it. I mean I know Mary and Tom, they've certainly done a lot with regard to lean but in terms of the detailed product processes I haven't seen that. And it used to be called concurrent engineering, so there is a few names, in new product engineering, new product design --development-- and there is people who do that but no there's not so much in the agile community. The agile community is doing all the good things about how they work inside of teams.

Right, it is bit like the objects and components, right?

Same, same issue.

Okay, so let's switch gears once again and let's look a bit at the state of research. So to give the context I am currently involved in a research project, deal quite a bit with universities and sometimes I am quite a bit frustrated about --

Yes --

I hit a nerve, I guess.

You will always be frustrated, it's university.

Yeah, so can you elaborate a little bit on the relationship or the lack there off between academia industry research development, how you have tech transfer and that kind of stuff?

Yeah, that's certainly an area that's really important for us and one where we've spent a lot of time. The biggest problem is that industrial relevance has actually hurt research, because one of the problems of -- if you take a graduate student, and they have to spend one-third of their Ph.D. effort figuring out how to make their staff work with Eclipse or J2EE or C#. Well I mean it's fine if they want to do that in their own time and, they want to be in the community I applaud that but often it forces people to use the wrong tools and the wrong thinking to come up with really new ideas but there is another problem is that the best model is customer's laboratory. So I think you want to be successful at the universities, what you want is you want the researchers coming to you, not you going to the researchers. So, bringing them into your business and having them work on your problem.

So in some sense you are saying two things, the one is that the purity of research is polluted by too early, too many specific technology things.

Trying to make it relevant and what that does is produce researchers who are trying to compete with the industry and in practice industry is already on a timeline. So if what they are producing is something that's going to be built within the next three or four years by industry. You know it's -- it's going to be irrelevant.

I've had this experience a couple of times at this OOPSLA, I was in the DSM workshop domains specific modeling and I saw two papers, actually one was last year but it doesn't matter two papers or presentations that talked about this new kind of cool thing, they just researched about and actually it was in my book two years ago and the book is not research stuff it's just best practice and that's one of the things where I thought, why are they spending their time on this kind of stuff? There is more challenging stuff they could look at.

Well, it's pretty shocking in the age of Goggle that people can't type in the keywords because you can in any new area, you can find almost all papers or the history of the chain. So I think there's a lack of scholarly work in many cases. There is pressure to publish and do new things and I think there's a lot of ignorance in many cases of the fact that what's been done. This is also partly a problem when there many professors and students who are disconnected from reality. People in the industry don't go and talk to them about the sorts of things they do. So but yeah I'm always again I sort of attribute to age but I'm always going. If I can type this into Google -- if I can type the keywords of the title of your paper into Google and get the missing references that you don't have. Why can't you find them? But I think the other problem is that the professors always constrict the students because simply the professor has an area and students are in that area and often the professor is the constraint. Your father prevents you from doing things and as much as an enabling you and so I actually prefer that the students have the research problem and then professors help to facilitate them. So when they are owned by the student often when these research consortia and things like that are put together. The agenda is, it's about getting the money. It's about getting the partners and they don't know why they're there.

Yeah, everybody does what they have always done under a new name such as --

Yeah, they just repackage what they are doing and I am sympathetic to the need for researchers in funding students but I think that the best thing is to get young people and bring them involved and say here is a problem. Now if you can solve this problem, this will be relevant to them because often they don't have problems. So they have to both invent the problem and the solution. I mean you see people doing language design and they have to design the application, they actually make an application that works with their language and they are coupled, right so they have no independent control.

Sometimes I think it should be the industry that comes up with the challenges and outlines, a kind of research agenda and then you have the researchers making it proof. Proving stuff, building a theoretical foundation, checking how far you can go and these kinds of things and I thought that would be more fruitful than as you said then the universities coming up with their own problems.

Yes, I think it's very important. I mean we've always subscribed to the model that the industry is laboratory.

Who is we?

The group of people I've always worked with and certainly all the stuff we did at OTI and we do at Bedarra. We really don't find -- we really can't do research if we don't have a problem, we don't have a customer. So it's sort of XP model of research, we have no customers. So, how could we know like this area looks interesting but we've -- it's so hard to focus because there are so many problems but if you have someone with a concrete problem and they say well we don't believe this can be solved or this would be important to us if you solved it, then that's an area where people can work toward and you have a benchmark that you can do it and you can even share it with other universities. So you can work on a common part and I think industry defining benchmark problems is very useful.

Yeah. Okay so to wrap this up, a question that I have asked several other people as a kind of final question. What do you think it takes to be a good software engineer or developer, programmer kind of person? What is it that makes a good programmer?

Oh, boy if I knew that it would be -- clearly the ability to deal with abstraction.

Modeling, conceptual modeling --

Modeling and conceptual modeling, clearly the ability to communicate and I think you have to have a passion for problem solving and I think you have to care about the code you write in the sense that it's just not enough to get it done. You've got to view it, you have to view it as an expression. I wouldn't go so far as to call it literature I mean the literate program that you really are not happy.

The sense of beauty --

You want to refine it till the point you want to polish it to the point, to the point that this is good. That this is something I am proud of, I've done it and typically reduce the blow to get it into a small compact form.

Cool, okay is there anything else you want to leave our listeners with? Any "pearls of wisdom" as I like to say?

No. I appreciate the opportunity to talk to your listeners.

Thank you very much.

I welcome their cards and letters and if they have some questions --

Fan mail --

Well, I don't know about fan mail may but the darts can come but I think being here with Fred Brooks and other people, you just appreciate that software is hard and making sure that -- I think mentoring and apprenticing. I mean the whole, that's craftsmanship that the whole -- that's really important. I mean if you really want to be good find somebody who is really good and try and work with them, right. Find someone who will criticize your work. So you have to get better and work with the best, right so and if you are the best in your organization, you are probably hurting yourself, right. Being three or four years or five years the best, you should be looking for someone else to work with --

No challenge anymore.

That's right; you will actually start believing that you are the best.

Yeah, okay so thank you very much for being on the show, Dave.

Thanks very much!