Steve McConnell: Software Engineering
Doug Kaye: Hello, and welcome to IT Conversations, a series of interviews with experts in today's hot topics in information technology. I am your host, Doug Kaye, the CEO of RDS Strategies, and my guest today is Steve McConnell, chief software engineer at Construx Software and author of many software development bestsellers including "Code Complete" and "Rapid Development." Steve is also past editor-in-chief of IEEE Software magazine, and his most recent book has the lengthy title of "Professional Software Development, Shorter Schedules, Higher Quality Products, More Successful Projects and Enhanced Careers." Hello, Steve. Thanks for joining me today.
Steve McConnell: Hello, Doug. Nice to be here.
Doug Kaye: Steve, those who have read your books think of you as a guru in software engineering, but I imagine you got started somewhere along the line as a developer yourself. What were your early experiences in software development that really influenced your approaches to programming?
Steve McConnell: Well, I think my experience is characterized by quite a bit of variety early in my career, and I think that has been a great asset to me as a writer. Early on, I worked for a small startup insurance consulting firm, and so I got to work on some pretty small-scale, fairly low-reliability software. I went from there to working on a large-scale government project for the Army, and so I got some experience on a more large-scale bureaucratic project, and from that point I went to work in shrink-wrap software industry, which is where I spent most of my career working on projects really of all sizes in that venue, and I think there is a lot of difference between the approaches you take that work well in those different kinds of software, and it has been a nice asset to have been exposed to all of those.
Doug Kaye: I noticed your first two books were published by Microsoft Press. Did you work at Microsoft?
Steve McConnell: I spent a year at Microsoft as a consultant, which was really valuable, I got to see Microsoft, I think, during its heyday, Microsoft working at its best, and I think that was really useful. In my first book "Code Complete," I think that if I hadn't been at Microsoft, I think I would have endorsed a lot of traditional software-engineering chestnuts a little too uncritically, but having seen how things at Microsoft worked, it made me a little more critical, and I think that was very useful for the book overall. Doug Kaye: Something along the way, Microsoft or elsewhere, must have made you say, "I see a better way to do this," or "I know what's wrong." What were some of those experiences?
Steve McConnell: Well, I think, like a lot of developers, I learned a lot of lessons the hard way. I personally participated in projects that didn't go very well or I ended up working a lot of nights and weekends, and so I don't think you necessarily have to know that there is a better way to think, "Gee, there must be some better way!" And at some point after I had been working in the industry two or three years, I discovered that there actually were books and magazines that talked about the better ways of doing things, but as far as I could tell, hardly anyone read them, and I think that's kind of where I came into the industry. I think that a lot of the books that had been written were quite inaccessible. They were written in, sort of, a professorial tone. They were written to students who had to read the books, but there weren't that many students at that time in those programs, and so I wanted to write something that would be a little bit more accessible to rank-and-file programmers. Doug Kaye: What were some of the books that you found inspirational?
Steve McConnell: The books I found inspirational? Well, I think the first one that I really liked was Yourdon and Constantine's "Structured Design" book, and it was quite eye-opening to me to see that anyone had actually thought through these issues before. When I read that particular book, I was involved in one project, and there was a nice distinction between two different high-level design approaches in that book. I realized that I was using the wrong approach, and that they had suggested an alternative approach that would work better. I think that was really the first experience I had that said "Hey, you know what? Other people have been down this road before, and I do not have to reinvent everything myself." Doug Kaye: The idea that someone had actually thought about methodology?
Steve McConnell: Right, and Philip Metzger's "Managing a Programming Project" was another book I read early on, and it's a nice book. I read the second edition, and the message in that book…it's a very prescriptive book. It says, "Here, run your project this way and it will do pretty well," and I think that's right. It takes a fairly document-intensive approach. It's quite a structured way of managing the project, but it certainly was better than the seat-of-the-pants approach that I'd been using before, so at least at that point in my career I found that very helpful. Doug Kaye: Now back in 1975, Fred Brooks wrote one of the first books on this topic, "The Mythical Man-Month," which is still a classic. This is based on his experience as a manager of development for OS/360.
Steve McConnell: Right.
Doug Kaye: In fact, you had a quote in of your books from Fred's book. What was your sense coming out of -- you know, that's going back a ways -- what's your sense from that and how Fred's experience influenced what you've done? Steve McConnell: Well, I think Fred Brooks is an extremely good writer, and I think very eloquent on the topic of software development. The fact that "The Mythical Man-Month" is still a popular book today almost 30 years after it was written is a testament to his writing and some of the insights in the book. I do think that it's tough to generalize from his experience. The OS/360 project had a peak staff of about 5000 people, and there just aren't very many of us who are working on projects of that scale. And so I think a lot of the issues that Brooks was wrestling with are not issues that the general programming population wrestles with. As I was working on my fourth book, "After the Gold Rush," I went through "The Mythical Man-Month," and the chapter titles in that book are quite poetic in a way, and it makes it a little hard to see what the book is really about. And so went through the table of contents and basically re-titled all of the chapters so that I could get a better sense of what the scope of the book was. I was quite surprised at the end of that to determine that, really, the book is mostly about documentation. It is about communication more broadly, but the specifics in the book really are about documentation. There is something like four or five chapters that are about that, and that was kind of a surprise because I wouldn't have taken that away just from a casual reading of the book. Doug Kaye: Certainly it was influential and, if nothing else, it did point out the myth of the man-month concept, and there're a lot of things, although very few of us were ever involved, as you've said, with projects of that scale. I think there are some things we now take for granted that one weren't taken for granted at that time. Steve McConnell: Well, I certainly think that's true, and I think Brooks' insights into the communication paths on large projects are very relevant today. Some of the ideas of trying to keep your team small to minimize communication overhead, I think, are highly relevant to today's projects. The title of the book I actually would take a little exception to. I published a column when I was editor-in-chief of IEEE Software called "Brooks' Law Repealed," and the idea behind Brooks' Law is that, as Brooks puts it, adding people to a late project makes it later, and I don't think there's really very good industry data that supports that. I think there are a couple of factors that come into play there. The dynamics Brooks describes is that there is a deadline for the project. There is a perception that the project is late, so staff is added, and after that staff is added, the project comes in much later than anyone expected, so I don't dispute that dynamic. What I do dispute is the credibility of the estimates in the first place, and I think that it is easy to say, "Well, we added people and we overran our estimates; therefore, adding people made the project late," but I think what really happens in a lot of cases is the estimates were so far off that they really were completely ungrounded in the project reality, and you have no basis for saying whether adding the people made the project later or earlier. I think in a lot of cases it makes sense to go ahead and add the people especially because you are probably not as far into the project as you think you are, and Brooks' Law really only applies to the late phases of the project, not the middle or early phases. And so in that sense I had said that I really disagreed with Brooks', what he calls his, first-order approximation of "adding people to a late project makes it later." My rule would be, "Unless you have a really good basis for knowing where you are exactly in the project, go ahead and add the people because you are probably already later than you think." Doug Kaye: We have a great opportunity to track your own evolution because you've got 12 years of books that we can follow, so I'd like to take you down a little path with that right now. Steve McConnell: Sure.
Doug Kaye: I want to start with your first book, which was published in 1993 called "Code Complete," probably, arguably at least, your most famous of the four books. What was your objective in this book? Was it for programmers, for example, specifically?
Steve McConnell: My first book really was aimed directly at programmers. I had conceived the book really as programmer-to-programmer discussion, and I really was writing the book that I wished had been handed to me after I had been working about a year, so it really…my litmus test on what I included in the book was, "Do I wish I had known this several years earlier in my career right after I had started programing professionally?" So the target audience was quite easy to identify with for that book.
Doug Kaye: This book was focused in particular on development and procedural languages. Was OO still too new at that time?
Steve McConnell: In my opinion, it was. OO was certainly something that was gaining some momentum, but at the time the book was published, for example, Borland had a C++ compiler that had just become available. Microsoft still did not have a C++ compiler; they only had a C compiler and other languages. Certainly I'd done a little bit of work in SmallTalk, but that was not readily available, and certainly Java wasn't available yet. The first edition of Visual Basic came out shortly after the book was published. It certainly didn't have any object orientation, so in my opinion OO was still too new to have yielded practical lessons that I was trying to capture in "Code Complete." Doug Kaye: Do you think those lessons still apply even in a world where object-oriented languages are more common?
Steve McConnell: Well, I think one thing that we haven't discussed is that about two weeks ago I completed a manuscript for the second edition of "Code Complete" and so this is a topic that's very much on my mind. I would say that about 95% of the content of the first edition is still relevant. Cosmetically, I think it's a little off-putting because the examples are in outdated languages like Pascal, plain C and plain BASIC, but I think the underlying concepts are about 95% on target, but what's happened in the meantime over the last 11 years has been that there have been additional concepts that really make a superset of what I discussed in the first edition of "Code Complete" and those concepts needed to be addressed as well. Doug Kaye: When do you think that book is going to be available?
Steve McConnell: It will be available June 1, 2004.
Doug Kaye: Well, that's exciting. So three years later, you came out with another book, "Rapid Development." This was aimed, I think, a little more at project managers, is that correct?
Steve McConnell: Yes, that's right. Doug Kaye: And, in that, you introduced a number of lifecycle models. The one that sticks in my mind the most is staged delivery. Tell us a little bit about the different lifecycle models that you discuss there and the importance or significance of each of them now many years later.
Steve McConnell: Sure.
I think that the primary concept that I tried to introduce with lifecycle models in "Rapid Development" was the idea that there is no one best lifecycle model for all projects and, in my view, the achievement of rapid development depends on selecting the lifecycle model that is best suited to the needs of the project. And so I ended up identifying about nine lifecycle models, and I identified four of those as best practices, which would be best practices depending on the nature of the project. Staged delivery is a lifecycle model that is probably the most sequential of the models that I identified as best practices, and it's essentially a lifecycle model where you would go through a fairly linear definition of requirements and then a description of your architectural design, and then you'd deliver the project in a series of stages a little bit at a time. The advantage of staged delivery is if you have stable requirements and you have an ability to define an architecture that you're working in a well-understood area, then you can achieve a good efficiency and pretty high reliability software and get pieces of that software into the hands of your customers sooner. For other kinds of projects, though, I recommended the "spiral model" or "evolutionary prototyping" or "evolutionary delivery" all as best practices for other kinds of project. If I had to pick one lifecycle model that I had to use the rest of my life on every project, I would probably pick evolutionary delivery. Evolutionary prototyping is currently very popular because it's really at the heart of extreme programming, which has gotten quite of bit of currency the last couple of years, but I think that it's not really that applicable to high reliability systems, and there are other lifecycle models that work better, in particular evolutionary delivery. The spiral model is also a very effective model, but I think it requires a much more sophisticated user than evolutionary prototyping or stage delivery, and so I think it works fine in the hands of an expert user, but maybe it's a little harder to used by the average project manager. Doug Kaye: Two years later, you came out with what is, in fact, my favorite of the four books so far, "Software Project Survival Guide." What changed in the two years that caused you to want to write that book? What was different?
Steve McConnell: Well, "Software Project Survival Guide…" "Rapid Development" had been pretty popular and had been well received, won some awards and so on, but what I found was that "Rapid Development" really was not very prescriptive. It essentially was a cookbook of all the various things that you could do, but I found that there was some segment of the readership out there that really just wanted a book that said, "Here, do A, then do B, then do C, and your project will probably work pretty well." And so I conceived "Software Project Survival Guide" as one particular recipe for project success that would work pretty well for most projects most of the time. The assumption going into it was a little bit different. In "Rapid Development," I had assumed that the reader was intelligent enough and experienced enough to pick the practices that were best suited to their particular context. In "Survival Guide," I took almost the opposite viewpoint, which was I decided I would tell the people one way to do things and assume that they were intelligent enough to not do something if it didn't make sense in their context or to adapt it if it didn't make sense in their context. Doug Kaye: If you look at these books, including the new one, you know, you get the sense that you started with the problems of the code itself and the developers, and you've worked your way up into the project management area, and finally in the new book you're talking even more about the software development profession. Is that an accurate view of the progression of the books?
Steve McConnell: Yes, that's quite an accurate view of the progression of the four books. I hope to reverse that progression a little bit with the publication of "Code Complete" second edition, and then the book I am working on after that will be estimation, which is back to more of a hardcore technical topic, which I am really looking forward to. Doug Kaye: Now the new book was originally published in 1999, I believe, as under the title "After The Gold Rush." Steve McConnell: Yes.
Doug Kaye: Tell us a little bit about the genesis of this book.
Steve McConnell: Well, "After the Gold Rush" is the book that I had really wanted to write as I was wrapping up the first edition of "Code Complete." I started collecting notes for the books probably in early 1992. And as I was conceiving my second book, I thought about writing "After the Gold Rush" at that point, but I had surveyed several colleagues and determined that as far as I could tell, rapid development was really a more popular topic. I also thought that I did not really have the industry standing at that point to write a book that made general comments about the software industry at large. So I published "Rapid Development" and that was received, and I looked at the "After the Gold Rush" notes again and decided I still wasn't quite ready to publish that, and so I wrote "Software Project Survival Guide" instead. But as we approached the year 2000, I really thought that there might be more of an issue related to the Y2K changeover than there was, and so I thought it was important to get a book out that described how the software industry could be improved prior to that Y2K switch over. As it turned out, I think Y2K was a pretty big nonevent and, in fact, I think the fact that it was a nonevent is quite an endorsement of how effective software development has been overall. Not that it was easy to make that happen, but I think there is a little bit of a testament to how well the industry was able to mobilize and to have long lived and truly how reliable a lot of the software out there really is. So "After the Gold Rush," I think, with the timing that it came out, ended up being a little unresponsive to what was actually happening in the industry, and in addition, I think I had had to rush it a little bit to get it out by the end of 1999. Doug Kaye: In this book, you talk a great deal about software engineering. Specifically, early on, you describe the difference between computer science and software engineering. Can you tell for our listeners what that's all about? Steve McConnell: Sure.
I think that the distinction in practice is a little muddy, but in theory I think the distinction is quite clear. Traditionally, science education prepares a student to do additional research that will advance the field. An engineering eduction, on the other hand, prepares the student to become a practitioner who applies the science toward practical ends, typically toward economic ends or business ends. So I think if you start with that as a basis, the distinction between computer science and software engineering is pretty straightforward. True computer science education would prepare a student to do work that advances the state of computer science. Software engineering education would prepare a student to go to work as a computer programmer or as a software engineer. I think that that distinction is muddied in practice because for decades all we've have had is computer science education, and so some of those computer science programs are really much more science oriented, and some of them are much more practitioner oriented. But over the last few years we have seen the advent of numerous undergraduate software engineering programs in the United States, and I think that means that really we can have the best of both worlds. The software engineering programs can prepare practitioners, and that will free up the computer science program to do a better job of preparing to do research that advances the field.
Doug Kaye: You wrote that industry has become less and less satisfied with university output. Do you think that's improving now? Steve McConnell: Well, I think that there are some indications that the industry is quite happy with the output from the software engineering programs. They really have not been very many graduating classes nationwide at this point because the first program admitted the first class only about seven or eight years ago. And so we really have had a very small number of actual graduates from those programs. But the head of one of these programs told me that starting salaries for a student from the software engineering program is averaging about $10,000 a year higher than the starting salary of a student from the same university's computer science program. So I think that's one clear indication that industry really values that more practical, pragmatic orientation perhaps a little bit more than a more theoretical computer science education. Doug Kaye: If you look at two polarized technologies in the computer industry, and that would be typical software development at one end and the design of CPUs, let's say, at the other end… Steve McConnell: Yes. Doug Kaye: …they are remarkably different. I mean, if you look at it just from a reliability perspective… Intel has had a couple of problems with floating-point errors in some Pentium versions, but by and large, they can crank out an incredibly complicated product that works. We don't seem to be able to make software that is used by the same people as reliable as the chips that those people use, and yet, I think it's arguable that the hardware is at least as complicated. Why is that? What's fundamentally broken here? Steve McConnell: Well, I think that is an interesting question, and I'm not sure that I have enough expertise on the hardware side of that question, really, to answer the question. I would comment that I have over the years worked with a pretty good number of electrical engineers and, in general, I think that electrical engineers make very excellent programmers. Of course, there are exceptions, but in general I think many of the best programmers I've worked with have had an electrical engineering background. Having said that, the code that those people write isn't error free, and so how they get to the point where the chip is error free is a little bit of a mystery to me. Doug Kaye: It's almost two different worlds out there. You know, if our hardware were as buggy as our software, we wouldn't have a computer industry. Think of number of times my desktop PC running XP decides it needs to update itself. We don't have viruses that I know of that attack chip flaws, for example… Steve McConnell: Right. Doug Kaye: …but we still have ways to exploit the software.
Steve McConnell: Well, I think one difference is that the CPU really does not have as much responsibility for interacting with the messy real world as the software does, and so in a way the CPU, because it's really the heart of the machine, has a license to have a more pure existence whereas the software ends up doing all the dirty work. What I mean by that is if I look at an operating system like Windows XP, Windows XP has to be capable of interacting with literally thousands of video cards and disc drives and monitors and network cards, and there's a lot of messiness in the interacting with all those cards. Windows XP also has to be responsible for dealing with different versions of the CPU. To give a little bit of credit to the operating system programmers, during the time I was at Microsoft, I remember one discussion between two of the programers who were working on the part of the code known as GDI, the graphical device interface. There was a bug in some of the GDI code, and the more senior programmer was reviewing the work that the more junior programmer had done, and the junior programmer was confused about why this bug showed up on one machine, but didn't show up on another machine. The senior programmer looked at the code and said, and this is what he said, he said, "You idiot! Don't you remember that in this particular version of the Intel processor, there is a documentation error and that you have to insert a one-clock-cycle wait state every time you use this particular instruction?" The other programmer kind of kicked himself and said, "Oh yeah, that's right!" So I think that it's not 100% accurate to say that there aren't any bugs in the CPUs. In that particular case, the only reason you didn't see the bug as a user was that the systems programmers at Microsoft were writing codes that compensated for that. Doug Kaye: If you look at this concept of professionalism, in your new book you talk about a number of constituents, I guess. You talk about the software industry, you talk about organizations, you talk about individual software developers.
Steve McConnell: Right.
Doug Kaye: You talk about how each of these can advance themselves or the industry in terms of professionalism. What are some of your recommendations there? What do you think that organizations, individuals and the industry overall ought to be doing?
Steve McConnell: Well, I think the biggest gap right now, in my opinion any way, is the skills gap between the state of knowledge in the software engineering field versus the state of knowledge that the typical individual has. And there are lots of reasons for that, lots of good reasons, and lots of the reasons are simply that we have been improving so fast, it's very tough for the average practitioner to keep up with the improvement, though in a way it's an endorsement of how good the field is. But I think the leverage here, an awful lot of the leverage is really at the organizational level. We still have a reasonably robust job market in 2004, certainly an improvement from 2002 and 2001, and so people still don't really have a strong economic incentive to improve themselves. They can go get a job at a variety of places with their current skill sets, but I think organizations have a very strong economic incentive to improve, and I have a chapter in "Professional Software Development," Chapter 13, that talks about the business case for better software practices. And I make the point that improved software practices really are the last great frontier in business. We can achieve return on investments on the order of 300%, 400%, 500% as an ROI, and I think that if you look at business decisions in general, the improvements tend to be measured more on the order of 5%, 10%, 15% ROI, certainly not 400% or 500%. And so there's really a tremendous benefit for businesses to realize. It's in their economic interests to do that. I don't think that the individuals have the same kind of economic incentive to do that, and I think that things move too slowly at the industry level as opposed to the organizational level to really count on that making a big difference at least in the short term. So I really over the years have gotten more and more focussed on what leverage can be applied organizationally as opposed to individually or at the industry level.
Doug Kaye: And what specifically do you think those organizations ought to be doing?
Steve McConnell: Well, I think there are several things those organizations can do. One is they can structure projects in such a way that they encourage developers to work on them in a sane way. For whatever reason, I think most developers and development leads believe that their businesses want them to work at a hectic pace where they essentially disengage their brains and their good judgment and simply work as hard and as fast as they can even if that means working stupid, and I think that's very unfortunate. The businesses don't really want that, of course, but for some reason the developers and project leaders seem to think the businesses want that, and so I think that something gets lost in the translation between the business leaders and the project leaders. So I think more clearly chartering projects and making clear what the business objectives of the project are is one step. Another step is more staff development. I think it's in businesses' interests to improve the capabilities of each individual staff member, and since we're still at a state where most of the technical employees of a business haven't had a good undergraduate education, it means the business has to provide that in some way or other, and that has been a real focus of my company over the years, has been trying to help businesses enhance their staff capabilities. Then I think another aspect of this is just better software processes. That's really where the whole Software Engineering Institutes' capability maturity model comes into play, and I think that's a very good aide along with some of the more human-centered developments that need to occur at the same time. Doug Kaye: Now, all of this is coming at a time when we are coming off an economic cycle where business executives very much are feeling they've spent too much on IT. They are looking back over the last…they look at the 1990s and they say, "We spent a ton of money and, you know, we didn't get much for it at the end of the day." They've cut way back. They are asking CIOs to do more with less. How can a CIO go to business management and say, "We want more respect for that. We want people now to be able to do it right and not feel the pressures of time," when, in fact, people say, "Well, gosh! we gave you everything?" Don't you have a sense the times have changed a bit? Steve McConnell: Well, my sense may not be as broad as yours, but from the clients that we've talked to you, my sense is that a lot of businesses now are feeling that they learned some lessons the hard way during the tech run up of, maybe, 1996 through 2000, and they're understanding that maybe it's a good time now, while things are not quite as hectic as they were a couple of years ago, to retrench a little bit and to upgrade the skill set of their staff. And so I think that what we have seen in the companies that we work with is that business are typically not on hiring sprees; they are being asked to do more with the existing staff, and so they understand that improving the capabilities of their existing staff is one good approach.
Doug Kaye: If you look out 10 years, a long time in this business, and probably a couple of books later for you, what's going to be different? How is software development and software engineering going to change between now and, let's say, 2014 and 2015? Steve McConnell: Well, I think we'll continue to see the same kind of progress that we've seen over the last 10 years. I think the industry has matured a very great deal since my first book was published. Some people might argue about whether some of those improvements really constitute improvements, but the fact of the matter is that I think there has been a tremendous amount of good material published over the last 10 years. When I published the first edition of 'Code Complete' 10 years ago, there really was no book on, say, software requirements that I could wholeheartedly recommend whereas now there are several on that topic. There were only a couple of design books, and those were a little sketchy at best, and now there are numerous design books, any of which I could recommend quite enthusiastically. And I could go through a variety of software development activities and make the same statement almost across the board. Publishing books by itself doesn't mean that the industry is improving, but I think in terms of codification of good practices and creating materials that are ready and waiting for a motivated practitioner to look at, we've come an awful long way. At the same time, the university infrastructure has improved. We have a couple of dozen undergraduate software engineering programs at this time which we didn't have 10 years ago, and every indication is that we'll see many, many more over the next 10 years. I think we'll continue to see the codification of good practices in books and articles and other sources over the next 10 years. I think we'll start to see some influence of the very well-trained young people who are coming into the industry maybe applying some upward pressure on the less well-trained senior people who are already in the industry, and I think that'll be positive in the long run as well. Then I think we'll continue to see good practices. One thing I found very encouraging over the last couple of years is the fact that we are having a fairly vigorous public discussion about the merits of extreme programming and agile development. I personally am fairly lukewarm about extreme programming," but I think it is terrific that there is enough interest in software practices across the industry that you read articles about it in Wired Magazine. You read lots and lots of articles in the more programmer-oriented magazines, and I think it's very, very healthy to have this kind of discussion about good software practices in public settings like magazines and interviews and books and articles. Doug Kaye: Why are you lukewarm on extreme programming?" Steve McConnell: Well, if I read the "Extreme Programming" book, and I don't pay any attention to anything else but the book itself, I think there are some good ideas there, and I would not hesitate in the right context, to refer someone to that book. If I encountered a client who had the right kind of technical environment and the right staff inclinations, I would say, "Sure, here's a good approach that I think would work well for you." So I think if you just stay within the four corners of Kent Beck's original book, I think there is a lot to like there. I think what's happened since the book has been published, though, is that the extreme programming movement has taken on a little bit of a life of its own, and I think in some ways it's a little bit like Frankenstein's monster in that the practice of extreme programming or the hype associated with it has gotten away from the original book. I don't object to the concepts too much; in fact, I like a lot of them, but I do object to the hype. I think it is one tool in a toolbox, and I think that there are appropriate times to use that particular tool, but I think that it should not be hyped to the degree that it starts to overshadow other valuable tools, and that's what I think has happened over the last couple of years. Doug Kaye: Well, Steve, I really have enjoyed talking to you, I've enjoyed reading "Professional Software Development," and I'm looking forward to the new version of "Code Complete." Thanks again for being with me today.
Steve McConnell: Well, Doug, thank you.
Doug Kaye: And I want to thank all of you for listening to today's edition of IT Conversations. This edition was recorded on February 3, 2004. My guest has been Steve McConnell of Construx Software; you'll find their website at www.construx.com. IT Conversations is a production of RDS Strategies LLC; please visit our website at www.rds.com. My name is Doug Kaye, and I hope you'll join me the next time for another edition of IT Conversations. This interview and many others are provided by ITConversations, please visit their website at http://www.itconversations.com
