e-Talk Radio: Lister, Tim, 10 October 2000

TEXT TRANSCRIPT: 10 October 2000
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Announcer: Welcome to Quality Plus e-Talk! with Carol Dekkers. This program will focus on the latest in the field of technology. All comments, views, and opinions are those of the host, guests, and callers. Now let's join Carol Dekkers.

Carol: Welcome to Quality Plus e-Talk! I'm Carol Dekkers. I'm a specialist in software process improvement. My company is Quality Plus Technologies, specializing in consulting in software process improvement, function point analysis, software measurement, primarily for the software industry. My guest this evening is Tim Lister, who has 20 plus years, I know that, in systems development, in team building, and he's a major player in a company called Atlantic Systems Guild. He's also the author of… together with Tom DeMarco, of a book called PeopleWare, which is in its, I believe, second printing, Tim, is that correct?

Tim: Second edition. We came out with a new edition last year.

Carol: Probably several printings, more than that.

Tim: Yes.

Carol: And we're going to talk today a little bit about PeopleWare, what's involved in PeopleWare, what inspired Tim and Tom DeMarco to write it. It's one of probably my favorite books in the information technology industry. And I'd just like to welcome you to the show, Tim.

Tim: Thank you, Carol.

Carol: First off, do you want to talk a little bit about what you do, what your background is, why PeopleWare to begin with?

Tim: Well, I'm even older and grayer than you think, Carol. I've been in the profession since 1972, and I'm a principal of the Atlantic Systems Guild. We're kind of a think tank. There are seven principal full partners, four of us in the States, three of us in Europe, and we have an office in New York. And I live and work out of New York, and we have an office in London. And we have all different kind of specialties in software and software projects, and I do mostly software project organization, software project management, I'm doing a lot of software risk management consulting these days, which is kind of interesting. And PeopleWare actually came out of left field for us. Tom DeMarco is one of my partners, and he and I put a seminar together, it must be 14, 15 years ago, called Controlling Software Projects. It was on management, measurement, and estimation. And we had gone through several iterations of the course, and it was going quite well. We got a lot of people from all sorts of organizations come to the course. We offered it through another organization that had been marketing for us, and so we'd do it about once every two months as a public course, then we'd bring it in house for bigger companies. And we were going through a new edition of the course, and we decided to stick a little section in before lunch on the second day, and we didn't even give it a number. We called it Section X, it was supposed to be kind of the free bonus section. We didn't even put it in the brochure in the first couple go-arounds. And it was… We named it PeopleWare, the section, and it was basically the hypothesis that most projects get into deep trouble not really because of technical issues as much as sociological organizational ones. You see projects that have major disappointments if not outright failures, and sometimes you look at them and it's really hard to find fundamental technical difficulties that defeated them. And you say, well, how could it be that this kind of a project turned out to be a debacle and a failure, and usually it's other matters at play. And so we tried it out, literally, on our guinea pig managers in the audience as a little half an hour session that Tom and I would actually stand up and do together, and we quickly discovered that we had hit a pressure point or something. And at lunch right after that session, people were full of stories to tell and things that they had seen that they weren't quite sure why things happened. And we literally started to collect ideas from all the developers and human developers and project managers who we got to meet, and discovered that we had a whole book on it before we knew it. And we ended up writing the book.

Carol: What do you think in terms of… publish the first book, based on a lot of stories that people gave you, a lot of information, primarily in the software development area, right?

Tim: Right. We're really talking about, well, the book is called PeopleWare, and it's subtitled Productive Projects and Teams. And we were looking at lots of different things. We were particularly interested in the phenomenon that we had seen firsthand, and I think everybody who's been in the industry can tell a story somewhere in their career, where a team somehow magically catches fire and it does an amazing job, where six or seven or eight or ten people were put together by the personnel department, and they never worked together, something clicks in and all of a sudden there's true synergy, and they do a remarkable job. And we started to talk to managers and people about how does that happen, and what's going on with that, and can you make it happen or can you increase your odds, or why is it some can gel, for lack of a better term, some can gel to really great, problem-solving groups, and others can use never much more than a gaggle of people.

Carol: And we've seen an awful lot of major software failures. There's the Department of Defense has billion dollar failures. Every software manager can recite 15 or 20 projects, and sometimes they'll go on and on about how projects failed and simply speaking, a lot of times they blame the teams. What kind of things did you see that were different, in particular, with the teams that had outstanding successes?

Tim: There are a couple of things that it turned out, it seemed to us. Teams that had great successes, well a couple things happened. One is the team itself kind of becomes a decision-making group. It almost looks like an elitist peer group. They'll decide all sorts of things. They start to take the project on in a way I don't think any manager can force them to do. They really bind to it. On a lot of projects, you'll see, if you really start to talk to people about what do they want to do on this project, they'll all talk to you about things they want to learn, new skills. Somebody says, well, this project's a Java project and I don't know Java very well at all, and I think it's really important with the new Web technology, and I really want to get my Java expertise up on this project. In second place is, we've got to the job on this project. On the gel teams, the goal on the project is, honest to goodness, build the best system we can for this. And that becomes the driving force. And these teams also, for the most part, you find out they're people who are all full-time on the project. They have one job to do and it's to build the system. Things like that started to show up where we had lots of, like I said circumstantial evidence of, kind of profiles of teams that had gotten very successful.

Carol: Now, do you think it has anything to do with the security? I know that Maslow's hierarchy of needs says that if your food, shelter and clothing is taken care of, you can get this self-actualization. Do you think that certain companies kind of breed that, or is it an individual nature that contributed to productive teams. Is it the leadership? What did you see?

Tim: Yeah, I think… Well, in terms of needs. One is, the one thing we found some people, we talked to people who had been on really successful teams. And they always talked about major decisions that were their decisions. Their kind of technical decisions. They always talk in the first person plural - "We decided to do it this way. And then we worked on this. And then we worked on that." And it was clear that, I guess it might be a hackneyed phrase, but they were kind of a self-directed group. They were good problem-solvers. If something came up that was a bit of a surprise to them, they'd put their heads together and figure out what to do. So, one, they had to feel like the decisions were theirs and not following orders. There were no orders to follow here. The goal was to build a successful product. And they also, it was their job not only to build it, but to find the path to success. Rather than being told what to do, day in and day out. So one, they had to feel like they were making decisions, and two, to be honest, you have to feel like you're not going to be second-guessed on every decision. There are so many decisions to make on a project. Some may not work out perfectly, and you've got to feel like you're not going… you're making a call, and if it doesn't work out perfectly, we'll figure out how to deal with that, and you're not going to be unduly criticized. So it becomes a quick decision-making group. They keep a good, high pace going.

Carol: It sounds almost like certain teams just kind of happen by cosmic reality or something. That something just happens and it's kind of a flash, fleeting moment that you're on a project that's great, and then you can't necessarily recreate it. I think some of our listeners may have some experiences they may want to share or that they may want to talk about with us. So I'm just going to provide the toll-free line real quickly. It's 1-866-277-5369. And if you're interested in sharing any of your experiences with software, you're welcome to phone in. I think the other thing that I've noticed, we've talked to a number of people, we've talked to Howard Rubin, we've talked to Frank Mazzucco, about software process improvement and the fact that software is a really tough thing to do. Frank Mazzucco says, he quoted a fellow who said, I think it was Don Canuth, that said that it's the hardest thing a human being will ever do in their lifetime. And we talked a little bit about the requirements. Do you think that the user community, the external forces, do those contribute to a productive team, or is that kind of just a symptom, just part of the environment?

Tim: Well, the teams that Tom and I write about, and have had the chance to talk to people about, are complicated peer groups, so they are made up of different experiences and things like that. Usually, a team, in order to be a real high-performance team, has to find a bridge to its client base or its customers, its users, whatever you want to call it, to get quick feedback and information. I mean, if you want to kill a project, all you have to do is make sure that the end users and the customers are a good distance away from the users, and they have no direct access. You can do it the other way. You can start to say, "What would you do if you wanted to make sure a team wasn't successful?" And I'm sure we'd all come up with a huge list of variations that we've all seen work. And one them maybe is, you can watch a team collapse out of frustration, because they don't have access to let's say the domain experts in the area that they're trying to build a very complicated application. Now the client will hand you the new hire who's supposed to be the single point of contact. And they don't know anything. And now you just want to fire up and get going, get going, have this huge bottleneck to get answers and feedback. And you can't kind of run open-ended for a long time without going back and saying, "Here's another piece of the prototype," or "We're thinking about this. Does this make sense to you folks, since you're going to be running the system or using the system?" So, from that point of view, teams have to feel like, I don't know how to put it, there's a support mechanism on the application side, on the customer side, that they want it, they're willing to spend some time with you, and you can get quick answers. That's very important.

Carol: Right. Well, we're going to be going to a quick break, and we'll be back shortly.

Welcome back to Quality Plus e-Talk! And my guest this evening is Tim Lister, who has many years, he told me more than 20 years, in systems development, and has been a major player. He's one of the "Big Seven" in the Atlantic Systems Guild. He has written, together with Tom DeMarco, a book called PeopleWare, which focuses on the people issues to do with software development and system developers. And Tim, you just mentioned that it's been translated into six languages, and has there been any particular country that has responded more favorably than another country?

Tim: Actually, for reasons I have no idea why, it has sold very well in Japan and in Germany. If you read the book, actually it's pretty funny, is, Tom and I wrote this book to try to make it as comfortable a read as possible. I mean, we envision somebody on an airplane going on a business trip or something. It is written in conversational, vernacular American. And we never thought about translation rights or anything like that. We just hoped that a few people would read it when we wrote it, and we were trying to see if we could write a book that people would actually get to the last chapter. So we had some really funny times with the translators, because they were trying to translate American slang, and they would come back to us and ask us to explain what a term meant. If we used an American term that was very hard to explain…

Carol: Right. And it's very, very effective. I found that the first time I read PeopleWare, when I read the first edition, that it was such an easy read. It was great. I loaned it to a number of friends, and ended up not getting it back. And then I went out and bought the second edition and found it equally easy to read. And yet there's so much meat and potatoes in there for software developers, for actually any technical professional or anyone managing any type of project.

Tim: Right. Yeah. I mean, we worked very, very hard on… We had really tremendous editing from Dorset House, our publisher… on everything from writing and rewriting sections to get a human voice, is what we kept on talking to each other about, as though you were hearing it from us as we're sitting around the table after lunch talking about these things. And we worked hard on the titles and the subtitles and yeah, it's a very, very important aspect of our work. For all the talk about technology projects, they're enormously human. The work is… All the serious work, or as Howard was saying, or Canuth was saying, it's intensely human, intensely intellectual, and you can see when it goes right, it's a true joy.

Carol: And, is that happening more? Have you found that you've had an impact in, and this is probably an overstatement, have you seen an impact in the response of people to PeopleWare? I know that the personal software process that Carnegie Mellon University, and the Software Engineering Institute, has put out, and the team software process has got to be building on some of the concepts that you and Tom first introduced in PeopleWare.

Tim: And to be honest with you, Carol, our industry is so big and so sweeping, I don't think we can claim any sweeping victory at all. Previously, there were some organizations and some companies who, over time, have really become aware of how important human continuity on teams, and things like that, and giving them a chance to succeed, has become. But the industry as a whole today, I must admit, kind of worries me a little bit with this kind of speaking out of the side of the mouth all the time now. I'm sure you see it in your business, Carol, the pressure for time to market and faster, faster, faster, get this done yesterday. That's fine to say, okay? The goal is speed, let's get it over as fast as we can, I can understand that. Then don't tell me to do it when I'm understaffed. I mean, a good baseball team has a good bench. If everybody's fully booked every day, there's no give in terms of things that pop up, things that might go wrong. No one has any slack to absorb all the things that pop up on projects. And so, here you are, an understaffed project, told to go at full speed. You can't optimize all dimensions at once.

Carol: Right. And at the same time, we've got the downsizing, we've got… You've got to do more with less, we've got ….

Tim: I think that's management code, "do more with less." Come on. How are we supposed to do that? Were we really stupid and slovenly? I don't think we've ever been stupid or slovenly in this business. And there's a huge demand, and clearly the demand has completely outgrown the supply of people who have experience and/or have serious interest in the software world these days. And I hear this in every nation. I was just in Britain and Germany, and you hear American managers saying, "Oh, my goodness. It's so hard to hire people, find people. I've got openings, I've got money, but I can't find anybody." It's the exact same thing I'm hearing in Europe these days.

Carol: And we will be back at the bottom of the hour with Tim Lister and more Quality Plus e-Talk! with Carol Dekkers.

Welcome back to Quality Plus e-Talk! I'm Carol Dekkers. I'm the President of Quality Plus Technologies. We are specialists in software process improvement, function point analysis and software measurement. I am pleased to present to you our guest, Tim Lister, who is a major player in the Atlantic Systems Guild. He's one of the seven major people, I guess one of the Big 7. He's the co-author with Tom DeMarco of a book called PeopleWare, which is in its second edition, has been translated into six languages, and has had enough royalties to at least buy a few things for Tim. I'd like to welcome you back to the show, Tim.

Tim: Hi, Carol.

Carol: And we've been talking a little bit about the people aspects, the team aspects, of software development. And this kind of fits in with our series of the show, and just what makes software development successful. And Tim's an international speaker, consultant, and lecturer. He also does software risk, and we've been talking a little bit about what makes a team successful. And one of the questions I've got is, we both subscribe or read a new magazine that's been out for about three years called Fast Company. And Fast Company, about a year ago, featured an article on software development companies, and the best places to work. And they featured a company, I can't remember their name, where they had hired primarily 20-somethings who knew Java and all the new languages, hired them for 70-, 80-hour work weeks. They ate, lived, breathed the office. Would take off on Friday nights on a company jet to Las Vegas, spend the weekend there and go straight back into work on Monday morning. And really, that was the life of the people in that systems development company. And at the other end of the spectrum, with equally high productivity, was a company called SAS, out of Cary, North Carolina. And they've taken a completely opposite stance, where they started investing in family-friendly programs for the employees, where people can take time off without any problem to care for aged loved ones, senior citizens, to look after kids. And Tim, I just want to ask you, what do you see with those two companies being so completely polarized and different, what do you see their chances of success in software projects?

Tim: Carol, you know, the amazing thing is… I've been in this business for such a long time, sometimes it feels that way… Corporate culture is so enormously varied, that when I go to a client for the first time, I've got a new client, I know enough now to know not to be surprised by anything. I can't guess what's going to happen. I think most people, people who have been in the same job for the same organization for a long time, you kind of, you're submerged, you're in the corporate culture, so you don't really sense it, and you need an outsider perspective to come in. Those two companies in no way surprise me. I see all variations or forms of that, where you can tell a story about one company to another company, and they can't believe it. And then you can tell the story back the other way to the first company, and they won't believe that. I have clients who are… I now keep track of what the local dress habit is, because the dress code goes from jacket and tie to Dockers to blue jeans to anything short of being naked. And I have a client where you can bring your pets to work. And so you'll talk to somebody and there's a Golden Retriever kind of slobbering on your shoes, and that's cool, and then you go tell another client that people bring their cats and dogs in to work, and they think they're insane. I think, especially now, what I'd say is, look, if the corporate culture you're in doesn't make you feel comfortable and safe and secure, and as though you're really participating and feeling good about your surroundings, take a look around. Now's a great time to interview other companies. It's turned the other way. You interview them, they don't interview you if you've got some skills. And find a culture that you fit. If you're a young, single person and think the best thing in life is getting into the corporate jet to work hard and play hard in Las Vegas, well, okay. But we all know, not everybody's thrilled with that culture. Nor would they be thrilled with the kind of maternalistic, paternalistic culture of SAS in North Carolina. You can have enormous variations and still have health. You're going to draw certain kinds of people. Clearly, not everyone is thrilled with the idea of jetting off to Las Vegas with everybody you work with all the time. You have a different life, and a family, and things like that. But certain people fit right in. What worries me is when the culture is kind of counterproductive, where people don't feel like they've got a real shot at giving their best productivity to an organization, and feeling pleased and satisfied with their work. I live in New York, and in New York, the cultures of the companies I see around New York City are hilarious. There's one company I won't name, because it kind of sounds ……., they're very, very aggressive. They pay better than anyone else, even in New York City, and they tell you, they say, "If you're really good, we'll give you a job offer. And if you work okay for the first year, we're going to fire you. Because you have to be very, very good." And they'll fire anywhere from 10% to 25% of their staff every year and then hire new people. And every year, you have to be really, really good and you get to play. And they work hard and they play hard. And they pay super well. And some people hear about this and say, hmmm, this sounds interesting to me, and I'm not afraid. Other people don't even want to have an interview.

Carol: That almost sounds like they're a certain tolerance for change, or… Your corporate culture has to kind of fit your own personality and what you feel comfortable with.

Tim: Yeah, and whether you're feeling like you're… Let's be honest, whether you fit in and feel as though your contribution is appreciated. Put it that way. Sometimes, if you're on a different wavelength than everyone else, it's just friction, it's difficult to deal with it. And given the market the way it is now, now's a great time to find an organization that makes you feel comfortable and appreciated if you've got skills. As long as it's not a destructive culture. I think unfortunately, I've seen a few of those, where companies kind of get pathological and kind of don't keep their eye on the work at hand. Worrying about power building, or empire building, and things are going on, and politics turned toward the irrational at times. Those are the kind of cultures that worry me, not the youth kiddie culture or the elderly corporate culture, things like that.

Carol: I think for… One thing that I'm hearing that's kind of exciting, I think, is that in today's climate there's enough variety, and enough variety in companies that if you're not comfortable in the job you're in right now, if you've got skills, you should be able to move. And there are probably some listeners who are saying, "I just hate my job. I hate what I'm doing. I hate my project. I hate the people I work with." What would be your advice to them to find a corporate culture that they'd feel comfortable with?

Tim: I think honestly, to take a step back for awhile and say, what is it that you dislike? Try to do a little root cause analysis and say, "What's going on that makes me less than thrilled to head into work in the morning? What would make me happy to get up and get going and feel like, okay, here we go again, this is going to be fun. This is going to be exciting. This is satisfying." Because is it the work, or is it the interactions with the people that you don't maybe have great respect for them, or some subset of people are giving you a real hard time, and most people are fine. Are you feeling that you're not challenged enough?

Carol: And we'll be back. Hold that thought. We'll be back with Tim Lister.

Welcome back to Quality Plus e-Talk! I have with me Tim Lister, who is one of the co-authors, with Tom DeMarco, of a book called PeopleWare, that focuses on teams and productive teams, especially in the software industry. Welcome back, Tim.

Tim: Thanks, Carol.

Carol: There have been two editions. And you had ten years between your first edition of PeopleWare in 1989, and your second edition in 1999. And I know it's been updated. What types of things did you learn, and what has changed in the last ten years?

Tim: Well, what we did was we took the first edition, and we actually left most of it intact, because it stood up just fine. But we wrote a whole new section, and added on, which is a section of I think eight chapters. So it's kind of an enlargement. And I guess the big difference is we, I think we made a mistake, we didn't realize it or we left it out, and memory fades, and Tom and I argue about this, but when you talk about teams in a book, especially in the United States, the U.S. and Canada, the default model of a team is a sports team. And we… That wasn't the right fit for teams that are project teams for software projects. And one of the things we wanted to talk about, and we felt that people didn't catch on to, was that there's a problem with a sports team, and one of them is to some extent, individuals on a team can win while the team loses. You can be an all-star basketball player in the NBA and be on a deeply mediocre team, and you can have the $10 million a year contract and be hugely wealthy and have beer endorsements and all sorts of stuff, and be succeeding, and yet the team isn't doing particularly great, the coach gets fired, and is in tumult, and attendance in the town may not be great. The model that we thought, that we actually talked about, in the second edition, was a different kind of team. And once you think about it, it fits perfectly. The team, the analogy of teamwork and software projects goes with musical groups - musical teams, so to speak, a glee club, a chorus. When you were a teenager, your rock band that played in the garage. Where the idea of internal competition just doesn't exist. You know, you're not saying, well I hope this person doesn't do so well, so I can look better. You're a 16-year-old kid, you just want the best drummer you can find for your rock band. And the better the drummer plays, the better for everybody. And you know, maybe it's my era, Carol, but the Beatles are a great team, where they have different personalities and bring different things to the table, but they weren't competing in that sense. You know, Ringo on the drums didn't worry about George Harrison - he wanted George to be as good as he could be. And I think that's the kind of teams projects… The great project teams are more like a great chorus than they are a great football team.

Carol: And if somebody is off, if it's an orchestra or something, and somebody is completely out of tune, it makes the whole group seem bad, and I think that's a pretty good analogy. If you've got somebody that's working against the team, or you've got a lone wolf, that sometimes happens on software projects, or you get, like the Software Engineering Institute talks about the ad hoc way of system development that isn't very mature and isn't very productive, where you have "heroes," and I always get a notion of somebody flying in with a Superman cape or something. And I think you're right. I think that really, software, to really build something good, takes a coordinated, choreographed effort.

Tim: Yeah, it's very interesting. I mean, for everything but trivial software, where you have got a group of people, you need a level of agreement, a level of communication, and a level of discipline. All the people in our business who complain about methods or process robbing them of their creativity, actually I thank my wife for pointing this out to me. She suspects that we have never been in the creative arts, because if you look at every creative art, it has huge discipline. You mentioned choreographed - my wife, we live in New York, and my wife loves the ballet, so we have a subscription to the New York City Ballet, Balanchine's old company. And I must admit, I wasn't a big ballet fan until I met my wife, but from a systems point of view, it's amazing to watch. The discipline of dance is awesome. The choreographer isn't saying, "Now, twirl around a few times if you feel like it." It's down to finger motions. And the work of the dancer to prepare for the dance is just total concentration. And so the creative… Yes, you know what, I think we are in a creative art, and I think yes, it needs enormous amounts of discipline.

Carol: Would you say then that you are a supporter of the Software Engineering Institute's Capability Maturity Model?

Tim: No. I worry about that because of only one thing. And that is, it's a scoring system. And I find life is much more complicated than grades A, B, C, D, E, or level 1, 2, 3, 4, 5. And people get… I see it all the time, they worry about going up a level to score well, rather than saying, "Where are we a little bit lax, or where are we a little bit short? Let's look at the key process improvement areas, the KPAs, think about what kind of software we build, where if we could improve we would get a real payback for that improvement and work that way?" I've got no problem with the CMM except for the scoring. Put it that way. The KPAs, all the fundamental stuff in there is terrific, and it's terrific to talk about it in the context of what kind of software and what kind of projects we have, and how do you interpret it as a framework for improvement? That's just fine.

Carol: And we'll be back to close up with Tim Lister after these messages.

And we're back with Tim Lister, and we've got a little bit of a wrap-up. We've been talking to Tim about productive teams and what makes a productive team, and whether it's process, whether it's people, technology, all these types of things. And I think you've found a lot of differences in your whole career, in terms of technology advancements. Have people really changed?

Tim: Boy. You know what, in our industry, they have, in a weird way. And the way they've changed is, the population is better represented. I'm kind of throwing you a wild card here. Two things: one is, I came right out of university and got a job programming, and everybody was a kid when I was a kid. I mean, my first job, I worked in a special group on Wall Street. My boss' boss' boss was 29, and that was the world. Because there was nobody with 20 years' experience in computing, so to speak. It was exploding, and so one, we've grayed, to be polite, and now we have people who are… Actually, I have a client who has kids who come in after school who are high school juniors and sophomores, who do Internet Web site maintenance for them and things. So, you know, we've got kids who are in 10th grade and folks who are in their 60s.

Carol: And that's an interesting kind of industry to be in, where we've got a lot of the older ones supporting the younger ones, a lot of the younger ones supporting the older ones. And I think it's a real testament to our society, to our IT society, that we can sustain that kind of thing.

Tim: The other thing I'd like to say is… The other thing I've seen, Carol, it used to be all guys. And now, thank goodness, it more looks like the real world.

Carol: And you've seen a lot more changes. I'd like to thank you, Tim. We could probably talk another three or four or five hours on this, and I'd probably like to invite you back at the end of our series of shows. I'd like to thank you very much. I'd like to give people the Web site for… It's www.systemsguild.com. There's a lot of interesting information there. Our Web site is www.qualityplustech.com. And I'd like you to join in next week, where we'll have an interesting guest, Mr. Jerald Savin, who is the President of the Institute of Management Consultants U.S.A. We'll be talking a little bit about what is the Institute of Management Consultants, for anyone who doesn't know, and what are the opportunities to get a certified management consulting designation? So Tim, do you have any sort of final words you'd like to leave our listeners with?

Tim: Yeah, given the things we've chatted about, I think our industry is going through another stage of growth pains in terms of doing more with less. But on the other hand, the opportunities and the interesting work seems to be more abundant than ever. And you really, as a skilled practitioner, I'm not saying you should jump ship or anything, but you should definitely be able to find a career with a peer group that is exciting and stimulating, and find a culture that you best fit in, and contribute wholeheartedly.

Carol: And I think those are good words. We've heard a lot of positive things about the software industry, and I think this week's show is no exception, that we've got a lot of positivism, if anyone's considering coming into the software industry, I think there's a lot of opportunity, and there's a lot of room for new people, older people, and I think basically, the software industry's one that you can grow up in and kind of stay a kid in some ways.

Tim: And it seems to be regenerating itself. Lots of little startup companies, and yet there are big organizations that have been in system building now for easily 30 plus years. And their technology's moving, so they're regenerating and re-architecting their systems. No one's short of work, let's put it that way. And interesting work.

Carol: And that's good news. I'd like to say thank you for joining us. And please join us next week, when we talk to Jerald Savin, the Institute of Management Consultants' President. Join us next week. Thank you.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.