Software Design and Development

with Code Complete author Steve McConnell

Hard to believe -Steve's classic "Code Complete" was published four years ago. At the time, the mix of method analysis and practical examples covering all phases of the software development cycle made it a indispensable read for programmers and project managers alike. We revisit some of the issues and techniques described in the book in light of the recent trends in software construction.

Steve McConnell is the author of numerous books and articles on software construction. He is a consultant to high-profile companies, most noticeably Microsoft. He is an editorial board member of "IEEE Software" where he authors the "Best Practices" column.

Code Complete: A Practical Handbook of Software Construction. Redmond, Wa.: Microsoft Press, 880 pages, 1993.
Retail price: $35. ISBN: 1-55615-484-4.
Available from Microsoft Press 1-800-MS-PRESS (1-800-677-7377).

Construx Software Builders Steve's consulting company, includes info about Steve's books and consulting activities
Steve's personal homepage
Code Complete page at Microsoft Press
Steve McConnell page at Microsoft Press
Steve's IEEE Software Best Practices columns

"my interest has always run in areas where there is the greatest leverage for improving software development practices, improving quality, making programmers get more satisfaction out of the work that they're doing and making the software better."

TNC: Welcome to the program. My name is Philippe Lourier. Our guest today is Steve McConnell. Steve is the author of the authoritative "Code Complete". He is also Chief Software Engineer at Construx Software Builders, and has also more recently authored Rapid Development and Software Project Survival Guide. These titles are all available from Microsoft Press. Steve, welcome to the show. 
SM: Thank you. It's good to be here. 
TNC: It's quite remarkable that this book came out five years ago in 1993. Did you have any idea at the time that it would have such a long shelf life? 
SM: Actually, I had hoped it would have a long shelf life. The kinds of topics that I discuss in the book are collected together precisely because they're more timeless topics than you often find in books that are more technology oriented. 
My big concern was whether it would last one year. I knew if it lasted one year, it would last five. 
TNC: How long did it take you to write the book? It's a very ambitious project. It's about 800 pages. 
SM: Yes, it's a big book. I started working on it about a year and a half before I submitted the proposal to the publisher. I was doing background reading and research. I worked on it full-time for eleven months and then it spent an eleven months in editing and production. So, when all was said and done, it took almost four years from start to finish. 
TNC: How does your book fit in the history of books about software development methodology? 
SM: Well, I think "Code Complete" was the first attempt that anyone had ever made to try to capture nearly all of what was known or what had been published about effective software construction practices. And so I think in that sense it was really something new that no one had tried to do before. There were some other books out at the time that had captured some small pieces of software construction. For example, Kernighan and Plauger's and "Elements of Programming Style" had been out for more than ten years. But it captured only a very small part of what made for effective software construction. 
So I was really trying to capture all of it. 
TNC: One aspect that made it immediately popular and stand out among the other books is that you not only talk about high level design issues, but you also go into the nitty-gritty and you're not afraid of giving code samples. 
SM: Yes, "Code Complete" contains about 500 code samples over its 800 pages. I do think that this is one characteristic that makes it useful. I personally learn best when I can look at examples. And I wrote the book as a book that I personally would have liked to have when I first started programming. So I thought examples were really essential. 
TNC: Where did the examples come from? Were they artificially constructed? Did they come from your own experience? 
My favorite are the "code horrors". You're not going to take credit for those, are you? 
SM: Well, unfortunately, I have to take credit for a few of those. Not that I'm doing any of those anymore, but those, some of the coding horror examples were examples that I personally committed fairly early on. 
TNC: Early on. That's the key¼ 
SM: Early on. Yes. Some of the coding horror examples were examples that I actually ran across in production codes. A few of the examples were given to me by some of the people who reviewed the book as I was writing the manuscript. And in the time since I wrote "Code Complete" I have had people send me dozens of additional coding horror examples. Some of them are unbelievably awful. 
TNC: Okay, Steve, we have to take a quick break. We'll talk about those examples when we get back on the Dr. Dobbs TechNetcast. 
TNC: We're back on the Dr. Dobbs Technetcast. 
Before we return to Steve, let me just give a few practical details here. You can join us in the chat room at, port 6667, in the tech.technetcast room. And any questions that you ask in the room will be asked to Steve and he will respond to them. 
Or you can call in questions at 212- 965-1390. 
Also I want to give out details about the book. It's called "Code Complete: A Practical Handbook of Software Construction," and it's available from Microsoft Press. 
Steve, I'm wondering about your background before writing the book. Were you a programmer? 
SM: Was I a programmer? I was a programmer and I still consider myself to be a programmer. At the time I, up until I started writing "Code Complete" I was working more or less full-time doing software development. And I think that's one of the reasons that people have responded well to the book, is it's written by somebody who is actually getting his hands dirty with real coding issues. 
TNC: Since the book has been published, with all your other activities, consulting activities and so on, have you been able to continue coding? 
SM: I have been able to continue coding, but I certainly haven't done as much as I was doing at the time I was writing "Code Complete." 
I'm trying to spend, these days I'm trying to spend about between a quarter and a third of my time actually writing code, and the rest of my time goes into writing activities and management activities, really. 
TNC: Is it hard to go back to coding? 
SM: For me, coding requires a great deal of concentration and a lot of immersion in the problem. It's hard for me to be really focused on a coding project and be focused on something else at the same time. And I think it's very much an activity where you have some state dependent recall. That is, a lot of things that seem obvious to you while you're in a problem, if you get away from it for a few weeks it's very hard to figure out later on. 
TNC: It's all-encompassing and draining. 
Now, before we get to the book, let's talk about your consulting activities. What are you doing now? 
SM: As far as consulting activities, I'm trying to spend a few days a month, and no more than a few days a month, going around to different companies and talking about effective development practices. I'm spending some of that time talking about "Code Complete" and I'm spending other time talking about my more recent book, "Rapid Development" and "Software Project Survival Guide." 
TNC: How would you contrast these works to "Code Complete"? What topics do they cover? 
SM: Well, "Code Complete" is a very detail oriented book and it's targeted at practitioners, people who are actually writing code. 
"Rapid Development" is targeted more at the person who has technical lead responsibility or maybe project management responsibility. I think there's lots of content in there that's useful to people who are playing individual participant roles in a project, but it's really most useful to the person who's actually deciding what the general course of the project should be. 
Then "Survival Guide" is even more big picture than "Rapid Development." It's intended to be used by project leads or by people who are involved in software projects, but not necessarily even technically oriented. Maybe people who are helping to define requirements or upper level managers, those kinds of folks. 
TNC: Why do you think your books are more and more removed from programming and higher- level? Do you think that will continue? 
SM: No, I don't. I don't think that's a progression or a trend that's going to continue. I think that it just came about that way accidentally. I think that with "Code Complete" I don't have a lot more to say about software construction practices than I already said in "Code Complete." I think eight or 900 pages is enough. 
But there's lots to say about other aspects of software development and my interest has always run in areas where there is the greatest leverage for improving software development practices, improving quality, making programmers get more satisfaction out of the work that they're doing and making the software better. 
So some of that comes into play at a construction level, and other comes into play at a technical management level, and I kind of go back and forth between the two. 
Book Structure 
TNC: One of the strengths of "Code Complete" in my opinion is its structure, and the fact, first of all, that it's so thorough, but also that it tries to catalog, name, identify all aspects, all issues involved in software construction. The structure of the book itself and its effort is probably as important as its contents. Would you agree with that? 
SM: I would agree with that. I think that when you have this much information, there are literally hundreds of different programming tips in "Code Complete." I think one of the author's big responsibilities of a book like that is to organize the material in a way that helps people understand the material. 
So I think the organization is very important. I've put a lot of work into the organization, much the same way a person would put work into designing a software program. I went through several iterations of a high-level design for the book and different approaches for the table of contents and had those reviewed by peers, and I really approached the whole book much like I would have approached a software project. 
TNC: And when the structure is valid, then you can almost remove some parts that maybe grow obsolescent or are not correct anymore, just replace them with other content. Just in the same way you would do it with code, where you would, when you encapsulate functionality in a routine, you could just replace that routine with something more relevant. 
SM: I really hope that's right. It's a little harder to update a book than it is to update software, at least I think it is. It costs more to print the book and bind the book and distribute the book than it does to cut a new CD and ship that. And I haven't had an opportunity to actually go back and test that in practice, to actually revise major sections of "Code Complete," but I guess time will tell whether that actually is true for the book. 
Reduce Complexity 
TNC: Now, another merit of the book is that it really decomplexifies the software construction process, and that is very similar to the way a programmer would decomplexify the problem domain and start writing software. 
SM: I would agree with that. I think that goes back to the topic of whether the book is well organized or not. But I think if the book is well organized and it gives intellectual boxes for people to put different coding ideas into, and the book talks about layout and it talks about control structures and data, and I think gives people ways to organize information. 
With programming, you have to keep track of so many different techniques and programming principles that I think if you don't have a good way to organize them, you're really going to get lost. So I do think that it's important that you organize those and come up with ways to simplify how you think about them. 
TNC: One of my favorite chapters in the book is actually towards the very end. It's "Reducing Complexity," I believe. 
SM: "Reducing Complexity." I think that may be one of the sections in the "Themes" chapter. 
TNC: Yes, it's at the end of the book. 
One of the most important skills for a programmer to have is really to be able to abstract the problem domain. And that seems to be a theme that occurs over and over again in the book. 
SM: I think that's right. One of the choices I made in presenting the book is that if this were a really academic textbook, the "Themes" chapter in the book would have been chapter number one. I would have laid out a lot of abstract principles and then the rest of the book would have been detailing how all those things played out. 
And in this book I took the opposite approach. I laid out all the details and then at the end of the book I tried to draw some common themes out from all those details. And managing complexity is definitely one of the big ones. I think that in some sense the main technical challenge people face in working on medium and large projects is keeping complexity from taking over the project. And so I do think that that's a theme that runs all the way through the book. 
I think that if programmers get nothing out of the book except getting into the habit of always asking, "Is what I'm doing making the project more complicated or less complicated", if they can get that one habit out of the book, then I think they've gotten something very valuable out of it. 
High-Level Design vs. Implementation 
TNC: Now, we're not going to go through the entire book, but you do describe the development process starting with high level design, and down to implementation. Where does high level design meet implementation? You start working on the design of the software, its requirements. Where do you have to make implementation decisions? 
SM: Well, I think that there are a lot of different approaches to that that come up on different projects. And unfortunately, one of the things about software development, I think, anyway, is that there is no one right answer. 
In that case, sometimes the implementation environment will be a foregone conclusion. You may know that the application has to work in Java or that you're going to be programming for a Microsoft Windows environment. And so that makes things easy, in a sense. 
In other cases, you may want to design your program in a language-independent way or in a platform-independent way, and that really puts a lot more distance between the high-level design and the implementation. 
In any case, I think that ideally, in an ideal world you would be able to do your designs completely independent of implementation considerations, and then you would later get the implementation and the design would work flawlessly. 
Unfortunately, in the real world, a lot of times you run into implementation considerations that bubble back up and end up affecting your design. So I think if you take a really pragmatic approach, you have to realize that there's going to be some back and forth. If you have to do some high level design work, try to make it as good as you can but then realize that implementation considerations are likely to bubble back up and cause you to change some of your design work. 
TNC: Actually, that's another theme common throughout the book. You never indicate that such and such an approach is the right approach. But you advocate more a pragmatic approach: try different tools, go back, rewrite, iterate. It's not a precise science. 
SM: I think that's right. That's true in a lot of different levels. 
One level is that it might be that there are a handful of people in the world who can walk into a project and who have the sophistication to be able to say, here's the right approach for this project. Let's do exactly this. And that will actually turn out to be the most effective approach to that project. 
But software development tends to be an activity that involves an awful lot of learning about what you're doing as you do it. And if you're working on a three-month or six-month or year or three-year long project, you're going to learn an awful lot about that project as you go along. 
And so just as a practical matter and also as a matter of risk management and cost effectiveness, you have to build into your approach the idea that you're going to be making mistakes. And so the challenge is not, don't make the mistakes. The challenge is, how do you make the mistakes quickly and cheaply so that you don't end up undercutting the project. 
TNC: Okay, Steve, we have to take a quick break. We'll be back here on the Dr. Dobbs TechNetcast with Steve McConnell. Don't go away. 
Steve's Website 
TNC: Welcome back to the program. My name is Philippe Lourier. We're talking to Steve McConnell. Steve is the author of "Code Complete, A Practical Handbook of Software Construction", now a classic now in the field. 
Let me just give Steve's home page, And Steve has a personal home page that you can get to from his professional home page, and the location is 
What kind of information can viewers find on your site, Steve? 
SM: On my personal home page, they can find excerpts from the books I've written, they can find the full text of most of the articles I've written and all of the best practices column that I write for IEEE software. 
On the professional web site, I did something with my latest book, "Software Project Survival Guide," that I think is a little unusual, which is that I created a really close linkage between the book and a related web site. So there are a lot of resources on the survival guide web site that are related to the book. 
One of the issues that I was struggling with in "Code Complete" is how do I include really up to date technical content in a way that won't make the book look like it's out of date six months after it's printed. And I didn't really solve that problem to my satisfaction. But with "Survival Guide" I managed to take the specific tools and other technologies out of the book, not really talk about them specifically, and I put them on the web site where I can keep the web site up to date and also not have the book look like it's out of date almost as soon as it's printed. 
"Code Complete" and the advent of the Internet 
TNC: So you're using the flexibility of the Internet. 
Now, the book was written five years ago, and at the time the Internet was not what it is today. How do you think development of web programming has affected maybe some of the concepts you describe in the book? 
SM: I think that the principles described in "Code Complete" are still very current. There is very little of the content in "Code Complete" that I would change as a result of web programming. 
However, I do think there are some very distinctive characteristics of web programming. I think programming in scripting languages kind of takes us back to the early days of Windows or the early days of DOS where maybe you don't have quite as full support, environmental support as you would like in some other kinds of environment. People tend to program in smaller pieces, so they're not working on huge, monolithic programs. They're working on smaller, somewhat independent or largely independent pieces. And delivery cycles are much, much shorter in many instances. A lot of companies are updating content on the web, including active content or what we might thing of as programming, almost continuously, daily or weekly. 
TNC: What do you think of this trend to always deliver betas, beta after beta, and never really deliver the final product? 
SM: Well, I think that really goes to one of the principles underlying "Code Complete," which is that there is really no one right kind of software development. 
Some kind of software requires very, very high reliability. And you couldn't in good conscience release that in a beta level of quality to a general public. For example, if you have an embedded software in a pacemaker control or something like that, you could never deliver that at a beta quality level with a clear conscience. 
TNC: Well, you could imagine having a Java-enabled pacemaker and you would just plug it into the Internet and then it would download the latest version of the software… SM: Right. That's not something I'm going to want to do any time soon… Java 
TNC: Now, Java has come on the scene, too. I'm sure you get this question a lot: "Where would Java fit into "Code Complete"? What are its characteristics?" 
SM: Well, I hate to say it, but I haven't really gotten into Java programming personally enough to be able to answer that question. From what I hear from other people, Java is a very exciting language, not just because of the relation to the Internet, but because it seems to be, it seems to take on a lot of the strong points of C++ without some of the weaknesses of C++. So I'm excited to get into it, but I'm a little behind the curve on that and just haven't had a chance to get into it yet. 
TNC: But there's really no reason why it would be different from programming in C++ or C from a software design construction approach. It's just another language. 
SM: From a programming principles point of view, the family of languages I talk about in "Code Complete" is a family called procedural languages. And Java, to the best of my understanding, Java fits into that group of languages, just as C++ or C or Pascal or ADA would fit into that group of languages. Certainly it has some unique characteristics, but an awful lot of the principles discussed in "Code Complete" would apply to Java programming just as much as they would to any other kind of programming. 
Design Approach 
TNC: Now, you describe two different approaches from a programmer's perspective to developing software. One is top down decomposition -- 
SM: Right. 
TNC: -- where you really start from concepts and you build them down to implementation. And the other approach is bottom up, where you would start from implementation requirements and then you would build from there. And maybe in the bottom up approach, choice of a language is a requirement, where in the top down approach it's not a requirement. 
It seems to me like the top down approach is really more probably used more often. 
SM: The reason I talked about those two approaches was not so much to say that in practice people use a pure top down or a pure bottom up approach. I see those two approaches as really being the two end points on a number line, with most people actually working somewhere in the middle. They're doing mostly top down with some bottom up, or mostly bottom up with some top down. As with many other programming activities, it seems to me that the most effective approach is to do a little bit of both and then to iterate through multiple design approaches. So you get the benefit of the top down view and the bottom up view. 
PDL and Pseudo-Code 
TNC: One of the tools you mention in the top down approach that are available to programmers is an abstraction tool, is PDL, Program Design Language. It's basically a methodology for abstracting code in English, something I think many programmers do naturally. 
How is PDL different from pseudo-code? 
SM: I use the term PDL pretty loosely in "Code Complete." There are people who would say that there needs to be a stricter use of that term, but the way I use it PDL is about the same as pseudo-code or about the same as structured English. 
I do agree that at a low level this is taking a top down approach. Programmers who use the technique I describe --writing out what you want the routine to do in English, converting those statements to comments, and then filling out the code below each comment-- find that it has a lot of benefits. It produces, it makes the coding go very quickly, it makes the coding relatively free from errors, and it leaves comments in your code when you're done that you don't have to go back and put comments in later. They're already in there just by virtue of the way you went about writing the code in the first place. 
So I think there are a lot of benefits. It's a good example of a technique that's actually very simple and somewhat deceptively so, in that it produces some really major benefits, considering what a simple practice it is. 
TNC: Many of the techniques you describe are, I would say, natural to programmers. They need to be defined, they need to be identified, but they seem natural and intuitive. 
SM: I get a lot of comments from readers of the book who say things like, "There wasn't all that much in "Code Complete" that was really new to me, but what was new was that I hadn't seen it written down before, and I really wish that I'd had this book ten years ago when I first started programming." 
Programmer Education 
TNC: Now, from your experience working with programmers, do you think many programmers desperately need to be educated about these techniques? 
SM: Oh, I think so. It's very difficult in an academic setting to teach students the kind of techniques that I describe in "Code Complete". You really have to be working on much larger systems to be able to appreciate why these kinds of techniques really matter. 
And so fairly early in a programmer's career I think they should be exposed to the kind of techniques that I talk about in "Code Complete." 
TNC: Don't Computer Science departments tend to focus on programming languages and not really the whole process of developing software? 
SM: Well, the way I started to look at it is that if you think of computer science as computer science, as science, most of the curriculum in computer science focuses on algorithms, data structures, numerical methods and that kind of thing. But not on actual construction practices. 
And if you think about it in terms of a physics curriculum or a chemistry curriculum or something like that, the construction practices really would amount to laboratory technique, web techniques to use in the laboratory. And I think that that kind of training at the university level really is very much lacking. 
Object-Oriented Programming 
TNC: Now, object orientation is also another natural way to abstract the problem domain. Is it the only way developers should approach software construction? What are its benefits and drawbacks? 
SM: Well, it's interesting. I submitted the manuscript for "Code Complete" in June of 1992. So object oriented programming hadn't really hit the mainstream yet. There were some articles coming out about it, but it really was not at all a mainstream program. 
In fact, Microsoft didn't have a C++ compiler available yet, if that gives one an indication of how early we were in object oriented programming at that time. 
I think that in the years since I wrote "Code Complete" people have discovered some pretty significant benefits and some pretty significant drawbacks to object orientation and C++ specifically. 
I think that the early promises of object-oriented programming as easier to understand than old-fashioned structured programming really haven't panned out. I believe object-oriented programs, in some respect, are better organized, but in other respects, the complexity of class hierarchies is added on top of all the complexity that was already there with structured programming. 
So in some respects object oriented programming is an expert technology. It gives you more power if you know what you're doing, but it gives you a longer length of rope to hang yourself if you really don't know what you're doing. 
TNC: So the drawbacks are that the design is more difficult to understand. It's more difficult looking at an object oriented program source code to determine what it does? 
SM: I wouldn't put it quite that way. Object oriented programming is a more powerful tool than structure programming was, and it carries the same benefits and risks that any other kind of power tool does, which is, used properly it's more beneficial. Used improperly, it can be more harmful. 
TNC: Is it maybe a problem of documentation? Object oriented programming needs to be accompanied with documentation, hierarchy diagrams for example, that make clear what the interaction between the different objects are? 
SM: I don't see it as primarily a documentation problem. I see it as primarily a design problem, really. If I ever update "Code Complete," I'll have a whole new class of coding horror examples that arise from misuses of inheritance, for example. And I don't see those as document problems. I see them as more like design problems. 
Naming and Commenting Conventions 
TNC: Let's discuss some issue that can be controversial among programmers -commenting techniques and naming conventions, these are religious issues for programmers. 
What type of response did you get to the convention you describe in the book? 
SM: I've been surprised at the lack of response to those topics. My personal experience on real projects is that those issues can be very controversial. As far as the book goes, I think it may just be that most people don't take the time to write an author if they disagree with what the author has said. 
So I get comments from people saying that they like the discussion of documentation or layout, for example, but I really don't get very many comments from people saying that they thought the discussion was way off base. 
TNC: What are the parts of the book that elicited the most reaction? 
SM: Well, the coding horrors I think are universally popular. People really like those. 
I think the main thing people like about the book is that it writes down a lot of practices that hadn't really been written down any other place. And so they're able to look in one place and read about what makes one effective construction. I don't know that there's any one chapter that people have written about or have thought was particularly valuable. I think it's just having everything collected in one place. 
As you pointed out, it's a big book, and when I wrote the book I never really expected anyone to read it cover to cover. I expected them to read one or two chapters at a time, and dip into the book in places where they thought something looked interesting. I've been surprised at the number of people who have read it cover to cover. 
TNC: When you start reading it, it's very difficult to let it go. 
We'll be back with Steve McConnell here on the Dr. Dobb's TechNetcast. 
TNC: Welcome back. My name is Philippe Lourier. You're listening to the Dr. Dobbs TechNetcast on the Pseudo Online Network. And we're talking to Steve McConnell. Steve is the author of "Code Complete." Here it is, on your screens, available in all good book stores, from Microsoft Press. 
Steve, we have questions from the chat room here. It goes back to OO programming. 
Freakout asks: "Is obliging the programmer to put more effort into design of the code one of the benefits of OO?" 
SM: I don't necessarily agree with that. I think that, properly practiced, it gives the designer a good opportunity to put more effort into the design of the program, but I think that if the programmer is working in a language like C++, the programmer has just as much opportunity to jump straight into coding without thinking about the design, as the programmer would have in working in a language like C. 
So I think that that's pretty consistent with the point I made earlier, that it's a more powerful tool with more powerful dangers in its misuse. 
Project Horrors 
TNC: Sprinkled throughout the book you have these coding horrors we have mentioned earlier. 
Let's move this to another scale - entire projects. Have you been involved -- and I'm sure you have -- with project horrors over the course of your consulting career? And why do projects go awry? 
SM: Projects horrors. Right. 
In "Rapid Development," I have a chapter called "Classic Mistakes." And that's probably as close as I get to coming up with a list of project horrors. But the origin of that was very much trying to think about what the analogy would be with coding horrors. 
One of the points I make in "Rapid Development" is that all kinds of different things that can go wrong. I enumerate three dozen classic mistakes in "Rapid Development." There are lots more mistakes than that that can come up on a project. 
Actually succeeding in a software project depends a whole lot less on not doing a few things wrong but on doing almost everything right. 
TNC: Now, I've been developing software for about ten years and I don't think I exaggerate when I say that 90 percent of the projects I've worked on were not successful. And when I say not successful, the problem was not that they didn't complete on time or they didn't include the features that were originally intended. But they didn't complete at all. 
SM: Okay. 
TNC: Is my experience representative? 
SM: I think your experience might be worse than average. 90 percent not completed at all is higher than any number I've seen reported for industry data. But a number like 25 percent not completed at all would be much more in line. And that's still pretty awful. 
TNC: And then another 25 percent. 
projects are completed, but without the initial feature set. 
SM: If you look at the remaining 75 percent of projects that are completed, you see that a very tiny percentage are completed on time, on budget and with the originally expected feature set. 
If you look at the various surveys that have been done, and I'm using some very round numbers, a quarter of the projects are canceled before they're completed and another 50 percent are completed over budget or behind schedule. And 25 percent are completed on time and on schedule, but the piece that's always missing from those surveys is how much of the original functionality was delivered in that 25 percent that was on time and on budget. 
TNC: So what are the causes of that? Such a failure rate would be unacceptable in the airline industry, for example. And it has become accepted that software projects are going to be late or will not complete at all. 
SM: There are lots of different causes for this. Generally, I don't think the cause is mostly ineffective development practices. I think the main cause is twofold. The first part is that developers are pretty good as estimating their individual work, but not nearly as good as estimating the work that goes into a whole project. So ineffective estimation is part of it. And the other part of it is I think developers tend to be a little bit optimistic about how long things are going to take. 
So you start out with kind of ineffective estimation practices coupled with optimism about the schedule, and you end up with a lot of projects that are severely underestimated from the start. 
TNC: How about the common complaint from programmers that specs change all the time as they are coding? 
SM: Yes. Specs do change all the time. So even if the initial estimates are accurate, the product definition is changing out from under you, and that's going to make the project take longer. That's very common. 
TNC: Talking about programmers, in the book you have a chapter on programmers and also a chapter or a section on character issues. How important are those? 
SM: I think that if a programmer wants to improve, that those sections are all important. At this point in history very few programmers leave their university training fully equipped to be a professional programmer. And so if someone is going to become a really expert professional programmer, it is incumbent upon each individual to make that happen for themselves. And so personal character becomes very, very important. Does a person have the drive to continuously improve their own capabilities? Are they willing to make some personal sacrifices to study books like "Code Complete" and other books, to learn about what other people know? Those kinds of issues really do become very important. 
TNC: Now, there's a myth, and I have to admit I believe in it, that the more programmers work on a project the less likely it is to be successful. And actually the best software is usually written by one guy, dedicated, motivated, capable. 
Is there truth to that? 
SM: I think that's kind of two myths wrapped into one. I agree with the first myth. There's some industry data that does suggest that the bigger the project the higher the likelihood that the project will ultimately fail. So I think that there is some substance behind that myth. 
I don't know how much substance there is behind the idea that the best programs are created by single individuals. If you were to look in the early days of DOS programming, I think that that was probably true, that at least for some of the really influential programs there was one main person behind those. But these days I think the industry's fragmenting. We may have a chance with Internet programming and some smaller programs for individual programmers to really shine again, but for more established programs like Windows I think it's gotten really tough for individual programmers to develop any kind of significant programs. 
TNC: It's definitely getting harder. At the same time, there's also a trend to consider here. When you program, you really program into an environment. The environment is becoming more and more overwhelming. The portion of your code that runs is insignificant compared to the other parts that are running when you your program execute -the operating system and so forth. 
SM: Yes, I think there are two major changes that have happened in that respect since I published "Code Complete." One is that at the time I published "Code Complete" people were making decisions about what programming language they wanted to program in. And now I think it's really true, people are making decisions about what environment they're programming in, such as Visual C++ or Delphi or Visual Basic. These are not just languages anymore. They're entire environments. 
TNC: Actually, there's really little mention in your book about operating systems, but there is a choice in operating systems, too. And that's a factor. 
SM: You mean between Windows NT and Windows 95 or -- 
TNC: Well, between UNIX, Linux, Windows. 
SM: Sure. I think any given programmer typically makes that decision. It's not a decision you make project to project. 
Current Plans 
TNC: It's product requirement. 
We only have a minute left, Steve. Can you tell us about the projects you're going to be working on now? 
SM: As far as writing projects, it looks like I'm going to be working on a book on software estimation next, which is a topic that I think needs to be addressed in a more readable way than it's been addressed so far. And other than that I'm just trying to continue writing articles and working on building my company. 
TNC: Okay, Steve, thank you very much for talking to us today. 
SM: It's been my pleasure.