The quality of the software you produce, the productivity of the people who produce the software, and the cost to produce that software is directly influenced by the quality of the process that's used to develop that software.
TEXT TRANSCRIPT: 3 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: Hi, and welcome to this week's show. I'm Carol Dekkers. I'm the President of Quality Plus Technologies, a consulting firm that specializes in quality initiatives, function point analysis, software measurement, and process improvement, primarily for the software development industry. This week, I'm very lucky to be able to be joined by one of my colleagues and friends, Frank Mazzucco, who joined COMPASS America, and international consulting firm, in 1998. He has over 30 years of application development experience. He's been a programmer, a database administrator, a manager and a management consultant. Prior to joining COMPASS, Frank was the total quality manager for Texas Instruments Software, and has been involved with systems development and the software industry for about 30 years. So I'd like to say welcome to Frank Mazzucco.
Frank: Thank you very much, Carol. It's a pleasure to be here.
Carol: Our topic this week that we've decided to talk about is generally the field of process improvement. We've had a couple of weeks when we've talked a little bit about what's going on in software. We've talked about the Dilbert Society, we've talked about team building. We've talked a little bit about cybergeography with Howard Rubin at the beginning of the series, and now we'd like to focus on a little bit about what's going on in the software industry, the software revolution, essentially, where software developers and programmers are waking up to the fact that sometimes they don't produce quality software. Frank, do you have any sort of lead-in words that you'd like to give, and some of your views on what's going on in software itself?
Frank: Well, we've really seen some changes over the years, Carol, probably going back about ten years ago. But there's been this realization, and it was sort of the still, small voice originally, but it started to grow louder and really grow into an actual movement, a revolution, as you say, that the quality of the software you produce, the productivity of the people who produce the software, and the cost to produce that software is directly influenced by the quality of the process that's used to develop that software. And so people are focusing in on that whole concept of what process am I using, how am I going about developing the software, how can I improve that software… I'll give you a good example. When I first broke into this business, and as you said, it was over 30 years ago, which please don't let anybody out there do the math on that to figure out how old I am, but there used to be a little cartoon which you still see every once in awhile, that showed one guy walking out the door and a bunch of people, a bunch of programmers, sitting at desks, and the caption was, "I'll go figure out what they want. The rest of you start coding."
Carol: And that's probably pretty true, still today.
Frank: And that's the point. You still see that today, you still see that happening. Actually, this happens at client sites all the time, where people are really not following a disciplined process for developing software. They're not getting their requirements right, they're not planning and managing their projects effectively. And as a result, the quality that they produce, the productivity of those groups, can be very, very low. But smart people have started to realize that if you improve… that the only real way to improve the process, the quality of the software, is to improve the process by which you build it. So you're starting to see, not just smart companies out there improving these processes, but you're also starting to see some standard frameworks that are being put in place to help people improve their processes. I guess a good example of this would be the Capability Maturity Model for software, which was developed by the Software Engineering Institute at Carnegie Mellon University, which is a good framework for helping you understand what things need to improve and sort of what order you need to go about attacking them.
Carol: Right. For anybody that's listening, that doesn't necessarily know how software's developed, umm, it basically starts with somebody sitting down with a programmer, I guess, traditionally, and saying, "I want a system" or "I want a laptop or something that will do certain things for me." Correct?
Frank: Exactly.
Carol: And then from there, once… that formulates the requirements essentially. And that's basically the way people start, isn't it?
Frank: That's exactly right. And what you'll see, though, is because the process of understanding requirements… Requirements are typically specified, of course, by nontechnical people, or specified by the business people who want to use the software, they're specified in English language, often in very fuzzy terms that "I want a system that will do such and such." By the time that those requirements get translated into the very precise programming languages and other definitions that are required for that to run on a computer, there's been so many translations and so many interpretations of what's happened that it's often like that old party game of starting at one end of the line and whispering in people's ears, and passing the saying along to the end, until you get down to the end and you've got gobbledygook that's nothing like when you started.
Carol: Right. And I think when you introduce the fact that a lot of companies don't follow a standard process… If we take the party game, the password party game as an example, and I say, "I want a system that will allow me to create customers, or create invoices," as an example. And then you decide that you're going to pass it to the next person, but you're going to write it down, and the next person says, "I'm not going to write it down, I'm going to whisper that." And the following person says, "No, no, no. I'm going to dance it." And the next time you go through the process, I think what you're telling me is that it's not standard, that we don't follow the same process from start to finish and that causes some problems.
Frank: That's correct, because first of all, if you don't follow the same process, then when people start a new project like that, they've got no idea what to do. Because they have to figure out, "Okay, how are we going to do it this time?" Like you said, last time we whispered it, this time we're going to dance it, or this time we're going to write it down. So you don't have that basic framework in place. And second, because you don't have that basic framework in place, you don't get any level of consistency. And that leads to poor quality, it leads to a lot of rework, which of course leads to increased effort, increased time to deliver, lower productivity, sometimes lower morale among the people who are developing the software.
Carol: Right. And I'd like to kind of ……… a couple of steps. Let's talk a little bit about what kind of caused this? Is it an educational flaw? Is it people are stupid, or what causes these problems in the first place, and then maybe talk a little bit about some of the solutions that you and your company apply to clients, and some of the things that you've seen and some of the things that can help you ……….. And then to kind of finalize with a little bit about where's the future going? Does that kind of make sense?
Frank: Sure. It sounds fine to me.
Carol: Okay. What have you seen in terms of… do you think we have a flaw in our educational system? Are we teaching programmers to just start programming and just start coding? That's what I've heard. I know when I went to school, we came out of school, and to do requirements and analysis and design, you know, we'd sit down, engineer to engineer and say, "What do you want me to code?" And the person would say, "Well, I kind of want you to code this." And you'd say, "Stop. Let's start coding." And I'd bring it back to them, and they'd say, "No, that's not anything like what I want." And I'd say, "Okay, wait. Let me start coding a little bit more. Let me fix it." Do you find that that's still the way? Or is education getting better? What have you seen?
Frank: Well, it's partly education, Carol. It's also partly a cultural thing, which really plays off of education. I think a lot of what we're teaching in computer science, computer science engineering curricula, is very very good stuff and we're teaching people very good technical skills, which is great. People need those technical skills. However, the problem with software is there's an awful lot of interpersonal skills that you need up front before you ever get to use those technical skills. So for example, if you go to computer science school and you talk to the great … programmer or C++ programmer, that's fine, but you need someone who's going to give you the basics of how do you get those requirements out of your users, how do you get them stated in a consistent fashion every time? How do you plan and manage an overall project so that it doesn't run behind schedule? There's a lot of those, what I like to call basic blocking and tackling issues, to use a football analogy, that don't get taught as well, or that aren't recognized as important as well by maybe some of the people with higher levels of technical skills. And that's really the point, is if you were going to start a football team, you wouldn't start out on day one teaching them the double end round reverse flea-flicker play, or whatever it is, all the technical fancy razzle-dazzle technical things that everybody likes to do. What you teach them on day one is you teach them how to block and tackle, you teach them how to throw the ball and catch the ball, the basics. And the bottom line is yes, those other things are really cool, really neat when they happen in a game, but by and large the team that wins is the team that can block and tackle and throw the ball and catch the ball better than the other guys.
Carol: Right.
Frank: That's not always a real popular thing for people to hear, but it's those kind of basic infrastructure things that are sort of really the most important when you get to software development.
Carol: And do you think that… I know that we're taught the technical skills, we're taught the programming, we're taught how to code, we're taught how to do creative hardware design, creative ………….. Do you think it's an issue of trying to teach technical people, people skills? Do you think that's part of the issue? Teaching them communications skills, or that they're lacking in that?
Frank: Well, clearly, interpersonal communications, people skills, are very very important to this. But it's more than just that, Carol. It's also the fact that we try to instill in people, and this is not strictly just in university, this is once they get into the work environment as well, there is an attitude that quite often evidences itself that, "I'm a skilled artisan, I'm a very highly creative person, no one else could possibly write code the way I write code."
Carol: Right.
Frank: "And therefore, I can't possibly follow any disciplined rules. That's going to take away all my creativity, it's going to sap my real strength, which is coming up with creative solutions and doing things my own way."
Carol: Right.
Frank: Which is really unfortunate, because the whole idea of having disciplined processes isn't about sapping people's creativity. In fact, this is the standard argument about rigor versus flexibility that's been going on as long as I've been in this business. The real value of a disciplined process isn't that it takes your creativity away, it's that it focuses your creativity on the area where it really should be applied, which is "How can I best solve this business problem for my client?" Not on "How am I going to choose to write a requirements spec this time?" or "Am I going to write a requirements spec?" or "How do I have to have my project plan documented?" or "What kind of team meetings are we going to have?" Or things like that. Those are things that really aren't relevant to how are we going to solve that business problem for the customer.
Carol: Right. And that's an interesting perspective, that creativity, which oftentimes traditionally in engineering has been kind of stifled. I think that computer scientists traditionally rarely focus on some of that, and we've got much more creativity that's nurtured. So it's a very interesting whole world of software.
And welcome back. I'm Carol Dekkers of Quality Plus Technologies, and we're talking about software process improvement - how we build software, how we end up with software that isn't great quality. And anybody who's tried to link two pieces of software together, anybody who's used software, knows that the fatal abend errors that come up and say "what do you want to do?" I was in Japan last week at the world congress on software quality, and one of the presenters was talking about some of the initiatives going on in Europe, where he said some of our cars actually have a lot of software in them. And software quality's becoming a big issue when you've got 80% of your car functions being managed and controlled by software. And he said wouldn't it be something, and he showed a joke slide, if the braking system came up with a "What do you want me to do? The brakes are failing? Reboot. Abend. Ignore." And everybody laughed, and he said that's the real problem. And we're talking to Frank Mazzucco of COMPASS America, who knows probably more than most of us, through his client involvement and work for the last 30 years in the software development industry, about what software quality means, and what it's becoming. So welcome back, Frank.
Frank: Thanks, Carol.
Carol: We were talking a bit about what's going on in universities and colleges, and really why we have a problem in defining requirements, why we have a problem in software processes. And I was just going to ask you a final question before we move to the next kind of questions, Frank, and that is, do you think it's easier to teach business people the technical skills, you know, how to program and that type of thing, if they know the business, or is it easier to teach computer people the business skills, or is it a combination?
Frank: Well, Carol, it really has to be a combination. And a lot of that gets sort of honed in on an individual's own aptitude and own preferences. However, I think what we're seeing in the software engineering world is yes, you still need to have technical skills, but the days of the strictly technical only person, where somebody could sit in a corner and just grind out C code or C++ code or another language code, week after week, month after month, year after year, with no involvement with anybody, the sort of concept of you have a programmer over there and you just throw some raw meat into the cubicle every one in awhile and the code comes out. There's less and less of a need for that sort of thing, because software isn't this little esoteric thing that sits off in the corner by itself anymore. You may operating systems software and things like that that are less directly involved with human beings, but software's a part of our life everywhere. One of the things we were talking about before is just how much software is in a car, for example, like you said. Software in things like the baggage handling system at the Denver airport. Everybody knows about the situation at the Denver airport, that it was delayed in opening for I don't know how many months, six months, nine months, basically because of the software problems related to the automated baggage handling system. So to the extent software touches people more and more, you're going to need to have those people skills. Now, is it possible to take business people and teach them the technical side? Yes, you can do some of that, to the extent that we move to more and more high-level languages for specifying computer systems, for specifying software, we can do that. And the reality is, there are some situations where you can have business people developing software, there are other situations where you need highly technical people, and in most situations, you need some combination of the two, where you have a business analyst who fulfills more of the people skills role and translates in a very proficient and adept fashion those requirements into something that the technical programmer can then implement. But the real answer is that across that whole spectrum, whether it's business people or technical people, what you really need is good, sound processes, like I said, good, sound blocking and tackling skills across the whole software development lifecycle.
Carol: Now, I've heard from some people who have been system developers and programmers and artistes and creators and Java programmers and Web designers, that part of the problem is not on their side, but part of the problem is that users and customers are unrealistic or they demand levels of quality that are absolutely outrageous, that they want things to work just perfectly… And we'll come back after these messages and talk a little bit more about ……… what we can do on the user side and ………….
Hi, welcome back to Quality Plus e-Talk! I'm Carol Dekkers, I'm president of Quality Plus Technologies, which is a management consulting firm based in Florida, which specializes in quality initiatives, software metrics, process improvement, and function point analysis. My guest this evening is Frank Mazzucco of COMPASS America, who has been a developer, software manager, for the last 30 years. We've been talking about why is software not great quality. What are some of the problems, what are some of the process things? And we went into the break with the question of is it really a customer or user problem, that, do we have unrealistic expectations? Are we expecting too much from software? Is it a matter of acceptance criteria? And I'll just point that question to you, Frank. Do we have unrealistic expectations? Do we expect software to be too perfect? What are some of the issues there?
Frank: Well, thanks, Carol. I guess expectations do play into it, because of course everybody wants everything to work perfectly and cost nothing all the time. However, I think really the problem we have is more the other way around, and really lies back more on the software developers, or software development management themselves. Having been in this business for 30 years, I think we have a tendency to take on all the requirements the users give us, try to implement everything the users give us and basically we never say no. And I think there's two real reasons for that. The first reason, of course, is we're nice people and we try to please everybody all the time. And we don't even stop to think about the fact that you can't please everybody all the time. The second part of it is, we tend to say yes when a user gives us a requirement, "Yes, we can do that by September 30," "Yes, we can do that by March 1," and "Oh, we can do that other thing by March 1, too, and that third thing and that fourth thing as well," largely because we simply don't know what we can do. People who don't have a disciplined process approach, who don't have any good metrics to understand what their process capability is, what they're capable of producing in a given period of time, simply have no idea when a user comes to them, what they can do. And so they just say, yes, we can do it. Now, the problem of course with that is, as everybody who's ever developed software knows, we get close to the release date, we start to realize, well no, we're not going to able to get all 50 of those features in there by next week. So we start cutting things out and saying, okay, this is going to be the core release, which by the way happens to be whatever we've got done at the time, those happen to be the core functions. Everything else will go in in release two. Well, we really do our users a disservice by doing that. If I were a user and asked for a function to be in your software, I would much rather know up front that you can't get it to me with all those other functions by the due date. Rather than waiting two or three weeks before the due date to find out.
Carol: Right. And I think one of our issues is the fact that although software is becoming more concrete and more a part of our everyday life, you can't touch and feel code. You can't tell, if a developer says yes, it will be done by a certain date, and we get two weeks up to the date, if it's a house, and you're at the framing stage two weeks before moving, you know that you're not going to move in. But with software, can you really do that?
Frank: Well, you can. Again, this gets back to fundamentals. Do you have good project estimating and good project planning and tracking mechanisms in place? So that you know how far along you are in the process. How many things you're getting done and what's likely to be done by the due date, what's likely not to be done by the due date. Do you have good metrics in place? Are you tracking historically how much software you've been able to produce in a given period of time? And applying that, going forward, to understand how much you'll be able to produce in the future. We talked a little bit about function points before. If you use the analogy of, and function points are just a rough measure of size, if you're able to produce ten function points per person-month, and your estimate on this project says you're going to produce function points at a rate of 40 per person-month, then you must ask yourself what's different about this project that I'm going to have four times better productivity than I have had before in the past? And the answer usually is, there's nothing different about this project, I've just grossly underestimated the scope and the effort.
Carol: And I want to be really optimistic, because this is going to be the project where nothing goes wrong.
Frank: Right.
Carol: And I think that's one of the fundamentals of the software process improvement, is that you need a process in place, a fundamental, structured, good process that will allow you to build in quality. And I know that you've got a favorite quote that I think you'd like to share with people about software defects. In terms of, we've got bug-laden software, and even if you use a good process, it doesn't seem like we can ever get bug-free software.
Frank: Exactly, Carol. The quote you're alluding to, which really goes back to the comment you made about this is going to be the project where nothing goes wrong, is essentially that there is no project like that. Donald Canuth, who's very well known in the computer science industry, in fact, is by many people considered to be the father of computer science, the father of computer programming, did a lot of some of the early work that turned this business from a cottage art into a more disciplined science. I'm going to paraphrase here. I heard him say one time that specifying computer software is one of the hardest things that the human race has ever tried to do. It's a very difficult thing to do. It's almost impossible to do it without introducing defects into the process. You pretty much can't specify and write defect-free code the first time. Which sort of belies a lot of the old quality sayings, "Do it right the first time" and all that. So what he's saying, essentially, is that nobody ever does it right the first time. But what he goes on to say is the result of that is that everyone who's involved in developing software, specifying, developing, implementing software, should spend their time looking for defects and trying to remove them from the process. The earlier the better, of course, but at any point, removing defects from the process. And this is a real change in mindset, a real change in attitude. If you take sort of the old-fashioned approach, if you found a defect in your code, whether you found it before it was implemented and the user started using it, or whether you found it afterwards, that was a bad thing. That was something wrong with you, because there was a defect in your code. There was something you did wrong. Well, what Mr. Canuth is saying, or Dr. Canuth is saying, is every defect you find should be a good thing, it should be a cause for rejoicing. Because that's one more defect that won't get out to the users.
Carol: Right. And I know, having been in software development, that oftentimes there's a sense of blame, that nobody wants to be responsible for a defect. Rather than celebrating that a defect was found before it went out in the code, before it went out to the users, people would lament and say, oh, you know, it's not my fault because of ……., rather than saying, hey look, I found something and detected it early!
Frank: Exactly.
Carol: And that is a cultural change. That's being able to work as a team and saying, you know what, something got in here that wasn't right. Let's make it right. And even if we look at the building construction industry, which is thousands of years old, having built a house, I know that even the master electricians who had 30 plus years of experience, sometimes put the outlet in the wrong place. And that's, you know, master plumbers, master electricians, they don't always get it right. So I guess it's kind of unrealistic for us to have expected software to be perfect.
Frank: Right. And I guess there's a natural analogy here. If you look at the total quality management movement, and where we've come with total quality management over the years, there used to be in the '50s and '60s, in this country probably even into the '70s as well, this concept that quality is the responsibility of the quality assurance department. We just produce stuff, whether it's manufacturing, or whether it's a house, or whatever you talk about. And then there's this QA group down at the end of the line that's going to inspect the quality end. And that was a very disastrous approach for many industries. I was in the steel industry for awhile in that time frame. It was a disastrous approach for us when other companies, Japanese most notably in that time frame, were building the quality into the process. And that's really the change in mindset. It's not that… If you take the analogy back to software, quality isn't the responsibility of the testing department, who's going to test the software after it's all written. Quality's everybody's job.
Carol: And on that note, we're going to go into a few messages. And we'll come back and talk to Frank Mazzucco of COMPASS America about exactly what quality means and where we can go with process improvement.
Welcome back to Quality Plus e-Talk! We've been talking to Frank Mazzucco of COMPASS America, and we've been talking to him about software quality and a little bit about software process improvement. There are a lot of initiatives that the Department of Defense in the United States, a lot of the governments, a lot of international standards organizations, and the Software Engineering Institute have focused in on in terms of the capability maturity model, the processes that we use in software, to develop better software. In your experience, Frank, with your clients, is there a particular model that works best, or is it just the structured approach to doing solid processes that works?
Frank: Well, the one that we see most here in the U.S., Carol, is the SEI Capability Maturity Model for Software, or CMM, as you'll hear. And that was developed here in the U.S. at Carnegie Mellon University in Pittsburgh. It was developed largely, originally to help DoD contractors develop software better, meet their cost estimates, schedule estimates, produce software procurements on time, within budget. However, what's actually happened with that model is people who started to realize it has wide applicability outside of the defense community. This has been happening over the last ten years. And have started to use it really throughout the development of all kinds of software, both real-time embedded software, management information systems software, large companies, small companies, are really starting to use this concept. And it's really not a prescriptive model in the sense that it says you must do this, this, this, this and this. What it provides you is more or less an overall process framework and sort of a hierarchy of what kinds of things you need to work on first if you're going to improve. For example, if you look at the SEI model, it talks about moving from the initial level, which is sort of the ad hoc or chaotic level, to the repeatable level, which is level two. And the way you move there is essentially by looking at management processes. How do you plan and track projects? How do you estimate projects? How do you manage requirements? These are all things that really relate to essentially project managers and above in the organization. They don't necessarily relate to individual software practitioners. The idea is, you get the management processes right first. Once you get the management processes right, then you can start to introduce specific best practices, things like peer reviews, for example, or specific kinds of training. You can start to deploy your standard processes across the organization. It's a very powerful framework. And again, it's not so much the actual names and the actual processes that go along with the SEI capability maturity model, it's just the concept of using them as a framework for process improvement.
Carol: And one of the things that you kind of glossed over that kind of piqued my curiosity is something that we both do in our practices, and that's tracking control, teaching companies how to track and control, and really measure what they're doing now, and then measure again once they've tried something new, which is the key to process improvement, identifying opportunities, taking a look at the differences through measurement, and then teaching them to really be able to do root cause analysis of what causes higher productivity and lower productivity, higher quality, and being able to go in and actually measure, track, and improve their processes so that they can get better software. Would you agree?
Frank: Exactly, Carol. In fact, that's one of the things… and I've seen this throughout the software process improvement sort of industry or sub-industry, that originally the people who did software process improvement 10, 12 years ago, told people well, don't start measuring right away, because when you're in that sort of initial ad hoc state, your results are going to be all over the map, you won't be able to do statistical process control, you won't be able to do this, you won't be able to do that. The reality is, you really need to start measuring right away and start tracking what you're doing even as you start your software process improvement program. And there's two reasons for that. The most obvious reason is you'll never know how much improvement you made if you don't start measuring today. And the second reason is, if you start measuring today, yes, your results may be all over the map, you'll have high productivity, low productivity, you'll have high quality, low quality. But you can start to use those data in some sort of a scatter diagram. You can start to identify where your best projects are and start to analyze them for best practices. Even today, as you're just starting to move forward. So yes, that's a very critical component of what you need to do.
Carol: And I'm going to do some blatant self-promotion, which we haven't really done on this show before. But one thing that my company does is teaches people to size their software, to go in and measure the size of their requirements. So it's similar to sizing a floor plan. If your requirements in software are your floor plan, we teach you to measure that size. And what Frank's company does, what COMPASS really specializes in, is in taking that standard size and being able to compare productivity and quality across a lot of different companies that they've gone in and taken a look at before. And in the comparisons, in doing better requirements, and doing the comparisons of companies that are best in class, that's really where some of the benefits of process improvement can be identified.
Frank: That's absolutely correct, Carol. And like I said, there's a natural synergy then between what you do and I do, because we really need each other to do this. And what people get in return is they get an understanding not just of how they compare against the best people in the world, as far as developing software, but how those best people got to be best. What things are they doing? What best practices do they have that you can adopt or adapt in your organization?
Carol: Right. We'll be back with a couple of email addresses and wrap up shortly after these messages.
Welcome back to our final segment. I'd like to give a great big thank you to Frank Mazzucco of COMPASS America, who has been with us for the last hour talking about software process improvement. So I'd like to say thank you for giving us your time, Frank.
Frank: You're very welcome, Carol. It's been a pleasure.
Carol: And I'd like to give out two URL or Web site addresses. One if the COMPASS America Web site, which is www.compassamerica.com, and the second one is www.qualityplustech.com. On each of those Web sites, you'll find more information about process improvement, software processes, some of the work we do, and some free articles that you can download or request. Next week, we're going to be joined by a prominent author, Tim Lister, who together with Tom DeMarco has written a book called Peopleware, amongst other things. And we're going to be talking to Tim about some of the people issues, some of the things that are going on in software, some of the future looks at what's going on with software, and give you some opportunities that you can call in and find out a little bit about what the people issues, and maybe even some of the career paths that you can go down in terms of software and the software industry in the future. So we've got probably only about a minute left, and Frank, would you like to give any final words in terms of software process improvement, or just a final farewell to our listeners?
Frank: Well, just a real quick comment, Carol, that really comes back to process improvement. I'm going to quote from a very unusual source for process improvement references, which is the Bible. There's a line in the Bible that says "change your hearts, not your garments." And what I'd say to you, if you really want to improve the quality of your software, change your internal process, change that thing that drives you. Don't change your tools, don't change your methods. Don't change your people, don't change your organization. Change your process. That's the software equivalent of changing your hearts.
Carol: And on that final note, I'd like to thank you again, Frank. I think that the COMPASS America Web site, people will find some valuable information, some white papers. And I think that throughout these weeks, as we talk about Quality Plus e-Talk, about software, about the software development industry, we're going to find some changes. And I think we've already seen some changes. There are some exciting things coming up in the future. I think that we've got some exciting guests lined up, and among those Tim Lister next week, who will be talking a lot about what do the people elements mean, and he's got some very interesting insights into his 30 plus years of software development experience. So please join us next week. Frank, I'm sure you'll probably be listening from some corner of the world as you're traveling a lot, and I'd like to thank everybody for joining in. And if you're interested in phoning in next week, the call-in number again is 866-277-5369, this is a toll-free number. And we'll be talking to Tim Lister, author of Peopleware. And meanwhile, if you'd like to send email, you can send it care of me, which is [email protected]. And if you've got ideas about shows for the future, we'd also like to hear about that. We'd like to thank you very much for joining in this week, and join us next week as Tim Lister will be talking about people issues in software development. On that note, I'd like to say have a great week. Talk to you next week!
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.
