McConnellComplete

DDJ: What is your philosophy of software development, in 250 words or less?

SM: Let's see. My philosophy of software development -- -250 words or less...

DDJ: That's not a hard limit, by the way.

SM: [Laughs] Good, 'cause I can't count my words and talk at the same time.

My philosophy has several elements. One element is that I'm pragmatic. I really don't care what the process is or what practices are used; the main thing I care about is the result. That has led me over the years to focus on process, but only because it seems to be the best way to get to results. If there seems to be another way, then that's what I would care about instead. Focusing on the needs of specific projects is another thing I feel strongly about. I don't think there is one approach that works well for all projects. That idea is ridiculous on its face, certainly if you're aware of the vast range of projects -- all the way from straightforward web projects that may not involve much programming (mostly they involve putting content up on a screen, in the simplest case anyway) over to highly complex avionics software. Clearly, very, very different approaches are called for. So some kind of variability on a per-project basis would be a key element of my philosophy.

Deliberateness is important. That is, not just doing something, but thinking a little first about what you're going to do and why you're going to do it -- making sure your effort counts. Learning from experience is an important element, too. I haven't said a whole lot about software in those comments, have I?

DDJ: No, you haven't. How does the technology impact your philosophy? For example, the Smalltalk culture leads to certain biases on the programmer's part versus a Cobol or Visual Basic or C++ culture.

SM: I have to be careful not to be misquoted on this topic. There certainly are challenges that arise from different technologies. But in terms of software development philosophy, I don't think the specific technology matters much at all. There's a general characteristic of the technology that matters a lot -- maturity. If you're working with mature technology, you can use practices that would be much more difficult or less productive to use with immature or volatile technology.

I don't see Smalltalk versus Visual Basic versus anything else as a huge driver for my approach. There will be different planning trade-offs I might make, but they will vary based on a lot of things, not just the technology. In an environment like Smalltalk, I may be able to change visual functionality quickly, and that will have some impact at planning time. But that certainly isn't unique to Smalltalk. I could be working in a database programming environment, or in Visual Basic, or in other environments that let me expose a lot of application surface area quickly. It's going to lead to the same conclusion. The fact that it's Smalltalk, in my mind, is not significant.

DDJ: Aren't there benefits to be had from, say, an object-oriented implementation that nevertheless require you to be experienced and intentional? The benefits don't just fall out; you have to engineer them. The technology only makes them attainable. Couldn't that impact your approach?

SM: Object-oriented programming languages tend to be more complex than older, procedural languages. By definition, the more features the language has, the more complexity there is, and, therefore, the more ways there are to get into trouble if you don't know what you're doing. I don't think that has anything to do with object-orientation specifically. It has to do with the breadth of the language.

DDJ: So you don't believe technology feeds back into the process level.

SM: Certain attributes of the technology do, but we would have to look at the specifics of a given case. We could find two object-oriented projects, maybe one's an embedded system and the other an end-user application. It might well be that the OO embedded system has more similarities to an assembly language embedded system than it has to the OO end-user application.

DDJ: How much insight do you have into Microsoft's development processes?

SM: I spent parts of two years on campus at Microsoft, and my office is two miles from their main campus. I've had all my books published by Microsoft Press. I have numerous friends that work at Microsoft. So I probably have better insight than someone who has had fewer connections with Microsoft.

DDJ: Can you comment on the apparent disparity between Microsoft's ability to create popular software and the notorious unreliability of some of that same software? Is it a question of the glass being half full rather than half empty -- that the software is working well enough? Or is the process not what it's cracked up to be?

SM: There are two questions there. One is how good Microsoft's software is. The other is how good Microsoft's development practices are. I see those as completely separate questions.

How good is Microsoft's software? Fred Brooks said 25 years ago that the real tiger is no match for the paper tiger. A lot of people are comparing Microsoft's actual software to some nonexistent ideal. The plain fact of the matter is, there really aren't any other companies doing what Microsoft is doing. There's no one to compare them against. You might compare something like Linux to Windows NT, but as far I'm concerned, you can't make that comparison until Linux gets to the same level of usability and driver support and backward compatibility and everything else that NT has. I'm not saying Linux is more or less reliable than Windows NT; I'm saying it's an apples-to-oranges comparison. Take one product that's 5 or 10 million lines of code and compare it to another product that's 50 million lines of code -- there's a huge difference between those projects. The same is true of desktop applications. If somebody produces one that works well on a handful of hardware configurations, that's a very different task than another company, specifically Microsoft, that has to produce software that runs reliably on literally hundreds of thousands of hardware and software configurations. There just isn't another company in the industry that has to do anywhere near the amount of compatibility testing that Microsoft does. So, before anyone complains too much about Microsoft software, they should point to any other software that operates as reliably under the same circumstances.

DDJ: Frankly, knowing what I know about the internals and the history of, for example, Windows 95, it's a miracle it works at all.

SM: [Laughs] I don't disagree with that.

DDJ: The early returns on Windows 2000 suggest that it's pretty darn reliable. If you were to ask me a year ago whether anyone could make 60 million lines of code reliable in a reasonable timeframe, I would say probably not. That's evidence of something right in Microsoft's development process.

One of the things I've always wanted to ask you is how you manage to do your day job and still crank out all those books.

SM: [Laughs] Well, that's a question that comes up in my life, too. I actually took time off to write my first two books. I had worked on Code Complete (Microsoft Press, 1993) as a background process for about a year and a half before I started writing it full time for 11 months. I made some significant personal sacrifices, but it was something I wanted to do, and it was worthwhile. Then I worked on software for two or three years before starting my second book, Rapid Development (Microsoft Press, 1996). Again, I spent almost a year full-time working on it. Then I went back to software work.

Then I tried to write Software Project Survival Guide (Microsoft Press, 1998) part-time, and it was a frustrating experience. I definitely prefer writing full-time if I can, but my professional situation didn't allow that with Survival Guide or After the Gold Rush (Microsoft Press, 1999). You can see the pattern my books have been taking: The first was 900 pages, the second was 650, the third 280, and the fourth was about 180. That's directly correlated to the percentage of my workday I got to spend on each book.

DDJ: My company underwrites my writing exploits to some extent, and I can write as a sideline on top of that. But you run a company; you're not sheltered like me. How can you write books on top of running a company?

SM: The nice thing about having my own company is that nobody's watching the clock. I am fully accountable for the results. I'm not accountable for being here a certain amount of time or for doing things a certain way. As a result, there are no artificial limits on how effective I or anyone else in my company can be. That's very liberating. An awful lot of people running a company will spend time on things that don't matter much. I don't spend much time on those things. I started my company in part so that I could create a place where people could do things like write books. I didn't start the company because we were going to head toward an IPO or because we wanted to become fabulously wealthy. I wanted a place where we could do real-world software projects in an enlightened way.

The result is, we have a company where people work close to 40 hours a week, we have a pretty generous holiday and vacation schedule, and we don't have a huge amount of thrashing on our projects, which can take up all the time. A lot of people in the software industry are productive, but what kills them is all the time they spend that's not productive. We try not to spend time unproductively.

DDJ: I second that. So much effort and resource is expended in Brownian motion at so many places -- having done a fair amount of consulting myself -- that it's the accidental complexity and not the essential complexity that kills you.

SM: I agree with that completely. A lot of people confuse motion with progress, and we try very hard to stay focused on progress.

DDJ: To what extent, then, do you trade off up-front analysis and design work for experimental implementation, or implementation, period? Is one to be done to the exclusion of the other, or do you feel your way, or something in-between?

SM: We take a look at each project and say, "What are the essential characteristics?" Is it the project that's going to have volatile requirements, and do we need to address that? Or is the application area well known, and if so can we do a minimal job on requirements and not expose ourselves to a lot of risk downstream? We take a very risk-driven approach, virtually identical to what I've written about. The approach is going to vary from one project to the next based on characteristics of the project as best we can ascertain them.

DDJ: One of the bad things about working in a research environment like I do is that you have to manufacture the risk all too often. Otherwise, you lose touch with that parameter.

SM: What do you mean?

DDJ: Well, I'm pretty self directed. I have to take the initiative in seeking out interesting problems and then making claims about why they're interesting and where they can go -- anticipating trends the research will track. I'm not doing pure research, knowledge for knowledge's sake. It's much more applied research. But it's research nonetheless in that a lot of what I've done with design patterns has involved going into existing software and looking for recurrences. I equate that with archeology or what biologists do in their taxonomic work. But I have to take the initiative. I don't have somebody telling me what to do. I know many people who dropped out of their Ph.D. program because they hated how "ill defined" everything was. That complaint is a sign that you're not cut out for research, because research is intrinsically ill defined.

SM: It sounds like you're describing why I became a software developer. I mean literally, one of the nice things about software is that you get something to show for your efforts. It's not concrete in the sense that you can hold it and feel it, but it is concrete in that you can execute it and see the results and get the satisfaction of creating something.

DDJ: By the way, I feel compelled to have you comment at some point on a language-specific level vis-à-vis C++. What words of wisdom do you have in that vein?

SM: [Laughs] I haven't done anything with C++ for, oh, maybe three years now. So I don't know how many words of wisdom I could have. Most of the programming work I've done in recent years has been in Visual Basic, believe it or not.

I like Visual Basic -- I'm not too embarrassed to admit that -- and I like it because I can get an awful lot to show for my effort in a very short time. Another thing I like is that it's a great example of a language where a little bit of software engineering goes a long way. If you approach a Visual Basic project with no software engineering discipline, you can get a lot of functionality put together in a hurry -- and then spend the rest of your life wrestling with that functionality. If you apply a little discipline, there aren't any significant limits to what you can do with it. Without that discipline, you're going to run into some pretty hard limits pretty early on.

DDJ: How broadly applicable is the knowledge and experience you've gained with Visual Basic?

SM: It certainly was useful for me to have done low-level programming earlier in my career -- some assembly programming, low-level C programming, working directly with the operating system calls, or even with the hardware in some cases. It's nice to get a sense of exactly what's going on at a lower level than Visual Basic gives you.

At the same time, though, the direction of progress in computing seems to be towards higher and higher-level languages. As something of an old-timer in the industry, I would say, yeah, everybody should have some experience working at a low level. But I'm not sure whether that's true or whether I just think everybody else should go through the same development process I did!

DDJ: The specter is that as a Visual Basic virtuoso I'd miss a bend in the road that requires a radically different toolset if not mindset, like, say, wireless applications.

SM: Well, I don't know. I think Visual Basic is today's Cobol, and there's a huge amount of development work going into it. I wouldn't bet against it. A person could probably stay busy at least for the next 10 or 20 years doing Visual Basic programming.

DDJ: That's a thought!

SM:[Laughs] Not that I'm saying I want to do that, but I think a person could do that.

DDJ: How much coding do you do?

SM: Very little for the last two years. The last significant coding I did was on a product called "Estimate Professional," a software estimation tool that won a Software Development magazine's Productivity Award in 1999. But the coding was done in 1998.

DDJ: How does not coding day-in and day-out sit with you?

SM: It sits with me fine. As I mentioned, I took almost a year off to work on Code Complete. I certainly was writing little bits of code, but I wasn't working on a big software project. And I really liked working on the book. But when I got back into a software project, I thought, "Oh, I really missed programming." I did that for a couple of years. Then I started working on Rapid Development, and I'd forgotten how much I like writing. Eventually, I figured out that I really like the variety.

DDJ: My sentiments exactly. I can get tired of what I'm doing without realizing it, except that I notice my productivity is not what it used to be. Sometimes I have enough sense to switch gears before it gets bad. But it seems the older I get, the less luxury I have to switch gears because of other expectations that have grown up around me.

SM: That's a very, very tough issue for people in our industry -- for the leaders in our industry. Maybe less in some of the technology-focused leaders and more in the software engineering or process-focused leaders, but a lot of these people haven't coded in 5, 10, 20 years or more. They start to lose credibility. Beyond that, an awful lot has happened in just the last five years. If you take some of the more prominent people in the software engineering field who have never done anything on, say, a desktop computer, much less anything with the Internet, their understanding of modern software development is limited.

DDJ: And yet these are the people who are looked to for sage advice. It puts them in a dangerous position, because they have a lot of influence but not necessarily the fundamentals.

SM: There are two ways to look at that. One is that these people have a lot of influence with some other people. But it's also easy to see that they've gotten out of touch, and a lot of practitioners simply dismiss what they have to say.

DDJ: I guess my nightmare is that I become one of them.

SM: That's my nightmare, too. And that's one advantage of having my own company. Before too much more time goes by, within the next couple of years anyway, I hope to get back in and play more of a hands-on contributor role on a project, at least so that I can get a taste of what's going on with the absolute latest and greatest technology.

DDJ: On that note, where do you see yourself going near-term? Any new books on the horizon? What are your long-term aspirations, and so forth?

SM: Well, for the next couple of years I'll focus on continuing to build my company. We have a lot of interesting things going on. We have a lot of professional development work with people already here, a lot of recruiting work with people we'd like to bring on board. For the next few years it's going to be important to make sure that technically and culturally my company develops the way I like it to. Beyond that, it'll be important to get back into more of a contributor role so that I don't become one of those people who've lost touch. Along the way I hope to write a book about software estimation. That's where I can give some good, practical, real-world advice that fills a gap. After that, I'd like to write a book on project tracking. There are a lot of good project-tracking techniques that aren't particularly labor intensive, but nobody's presented them under one cover.

DDJ