Software Development Practices: A Conversation with Steve McConnell

Editor's Note: Welcome to .NET Rocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show727, with Steve McConnell, author of several software development books, software engineering maven, and CEO and chief software engineer at ConstruxSoftware. Steve, Richard, and Carl converse on a range of subjects -- from executives' role in software development projects to the role of Agile andScrum methodologies to continuous integration.

Carl Franklin:Welcome, Steve. What have you been doing lately?

Steve McConnell:My attention has really turned increasingly toward what is needed to make software organizations run at the executive level. If you look at the progressionof books that I've written, Code Complete obviously started out very detailed, very in-depth, the workers in the trenches who were actually doingthe real work of a software project. Rapid Development was a bit more focused on technical leads and managers. And then my Professional Software Development book probably stretched a little bit too far maybe, and it was more of an industry-level book. But in themeantime, I've kind of thrown it all back a little bit, and I've been looking a lot more at what executives need to do to support really good softwaredevelopment.

CF:So when you look at the big, bad world of software development, do you find executives are getting in the way more than they're helping, or is it the otherway around?

SM:Well, I think just as with software development practice itself, there's a tremendous range of confidence among executives just as there is among hands-onsoftware developers.

CF:Sure.

SM:So I've had an opportunity over the years to meet some exceptionally capable executives, and from time to time I run into someone who I candidly would saydoesn't seem like they know what they're doing, and the problems are similar, actually. I think that for many years, well, we start with maybe projectmanagers… I would say over the past 10 years that actually has come into clearer focus, but I think in many organizations, what the director-level orVP-level person is supposed to be doing is quite unclear still.

CF:Yeah. My experience has been that as a manager or as an executive to sort of step out of the way and let the people under me do their job until it comestime to make the big decision. And then timing is critical, and of course, the decision is even more critical.

SM:I think there's always a fine line there. The really good executives do a great job of walking that line, but you have to be giving direction to the staff,you have to be setting a clear vision. That vision-setting process has to be collaborative enough that the staff buys into it. It also has to be directedenough that the vision is clear and isn't just a mishmash of different people's opinions.

I'm a big fan of setting really clear objectives, setting expectations early and often, and then getting out of the way once you've done that and lettingpeople do the work. You guide people based on [whether] they [are] performing to the objectives you've set. You don't try to get into the details of didthey do it the way I would have done it. As long as they're aimed in the right direction, you pretty much let them use their best judgment.

CF:Of the executives that have been very talented and very good at what they do, what percentage do you think have been software developers in the past?

SM:That's a great question. Due to the nature of the work that I do and how we come into contact with executives -- who are often people who read one of mybooks 10 or 15 years ago and have continued to grow in responsibility -- whether there's a selection bias in the sample or not, it's pretty darn close to100 percent have some software background. I could certainly name some exceptions, but that's probably 90 percent to 95 percent software developmentbackground.

CF:I look at a guy like Scott Guthrie as a really good example of that, you know, somebody who understands software at the bits and bytes level but also hasjust incredible vision and is able to rally his people to his cause and motivate people.

SM:Yeah. As you get into larger organizations where you have to have the management expertise and the leadership expertise to lead a staff of 200 or 500 or1,000 people, I think it becomes very difficult if not impossible for those people to maintain the technical chops that maybe got them promoted muchearlier in their careers. So that becomes a real challenge because you've got to retain the respect of your staff while also being honest about the factthat your technical skills might be 10 or 20 years out of date. But I think the good technical executives do in fact do that, and their staff respects themfor having been great technically at one time but now really being great as a manager and a leader.

Richard Campbell:When I think about really successful leaders of developers, they're the guys who run interference for the devs to let them focus on what's important butalso really push on better documentation or better understanding of the project or better training. I think often, especially at the development level, wejust try to get to the code too soon. Insisting on a clearer vision, insisting on more resources so the guys have greater chances of success, reallyfacilitating that success, is the defining difference.

SM:I think that's a really interesting point. What that makes me think of is that I think the job description for people once they get to the manager ofmanagers level or VP level is really pretty undefined in most organizations. I like the elements that you defined trying to free up technical staff toreally focus on the main work that they're doing, running interference, and then maybe making some of the toughest technical calls or at least making surethe product or project direction is really clear. But you know, it's interesting, I think there are very few organizations that have even attempted a jobdescription for the jobs at that level.

RC:I made the mistake, well, maybe a mistake, I tweeted that we're talking to you, Steve… and a storm came streaming in. One of the most common questions,several people asked this, was [about] your Code Complete, which really predates the whole Agile movement. If you were going to do a "CodeComplete 3," how do you see Agile fitting into that? I'd like your opinions on Agile in general.

SM:I think Code Complete is mostly at the level of detail that is largely oblivious to Agile or non-Agile. One of the things that I wanted to do with Code Complete when I first published it 18 years ago was to legitimize talking about detailed software construction issues. I think people mostlyassumed those practices -- they certainly weren't taught in school -- and I wanted to elevate the status of those practices and get them out on the tableand say, "Hey, we should be talking about the detailed ins and outs of coding and debugging and unit testing and [how] these detailed constructionactivities are done." I think Agile shared the spirit in the sense that Agile… well, in the Agile manifesto, the focus on working software and the focus ontrying to engage customers via the working software, and so on…. And then, the first couple of years of the Agile movement was extreme programming focusingon test-driven development and coding standards and pair programming, really activities and practices focused at the code level extended the emphasis thatI had been trying to achieve with Code Complete.

So having said that, I think there's maybe a shared emphasis there on detailed coding work, but otherwise what caused me to revise Code Completein 2004 didn't have anything to do with Agile. It had to do with changes in the programming environments and changes in the languages that people wereusing, really had more to do with the universal uptake of object-oriented programming, which we don't even talk about now because it's just the way thingsare done.

So, at the Code Complete level, I don't know, if I were to do a "Code Complete 3," and I have no current plans to do a Code 3.0, I just want tomake that really clear, it's at least five years before I would even contemplate thinking about a "Code Complete 3." I just don't think things have changedall that much. I think Code Complete 2 could probably use more of an emphasis on scripting languages than it had. Otherwise I think it's stillreasonably current.

RC: Sure, and actually in some ways a lot of Agile practice relates as much to project management as it does to the actual coding practices.

SM:I think certainly as Agile has evolved, I completely agree with that. Back in 2001, 2002, we would have had a different discussion, but these days I thinkwhen people say Agile, mostly they're referring to Scrum. I think Scrum, my description of Scrum or definition of Scrum, is that it's a project-leveltechnique for managing workflow at the project level. There's nothing technical about that except that the work is technical.

Just for the record, I think Scrum has clearly emerged as the best of breed of the Agile practices. We've seen many organizations succeeding with Scrum. Ithink it took us the first half of the past decade to get to that point. There were some false starts, but I think from 2005 or 2006 on, Scrum was inascendancy and still is, and we certainly see far more organizations succeeding with Scrum than failing.

RC:Right.

SM:So yeah. At Construx, my company, we're pretty high on Scrum. We have a lot of service offerings, training classes, and consulting because we've seen Scrumemerge as a best practice, and that's what we're focused on.

RC:It's not the only practice, but one that seems to be broadly applicable, and a lot of different teams of varying skill and size can be successful with it.

SM:Varying skills, for sure. I think that when you get beyond a couple of teams whose work has to be coordinated, I think by-the-book Scrum becomes morechallenging. The reason I say that is I go back to my definition. Scrum is really a project-level tool for managing workflow at the team level. I thinksome people say Scrum is great, let's scale it up to our 100-person project. I think that it's great to continue using Scrum at the lower levels of that100-person project. I think if you rely on Scrum to meet all your project management needs for that larger project, you're going to have some prettysignificant gaps because it really isn't Scrum's area of applicability. So we've seen companies struggle as they try to scale up Scrum, especially ifthey're being a little bit too purist about trying to only use practices that have some sort of a true Scrum label on them.

If you bring in a little bit of traditional large project management practice and layer that on top of mostly Scrum implementation at the team level --that can work great.

RC:At the time that you wrote Code Complete, you weren't all that keen on continuous integration. What's your viewpoint on continuous integrationthese days?

SM:I would say that my attitude has probably shifted a little bit as I've seen various companies experiencing it or using it effectively. One thing that'shappened with continuous integration is that the meaning of the label has shifted a lot. I don't know where the term originated. I first encountered it viaMartin Fowler, and at the time continuous integration really meant continuous, meaning you save the file and everything would be recompiled in thebackground as you continue to work.

RC:Right.

SM:The way the terminology has evolved, at least what we've seen, is a lot of project teams that will say we're doing continuous integration, and when we lookat it, it looks an awful lot like what I had described years ago as daily build and smoke test. With the daily build and smoke test, there was never theexpectation that individual developers would build only daily. The expectation was that the project would build at least daily and individual developerswould be building as often as they needed to, which could be five times a day, it could be 20 times a day. It was just depending how often they needed tobuild to be able to check what they had just created.

I think some people have interpreted that cycle as continuous integration, which I think is fine. I continue to think that there can be benefit in lettingthe code loosen up for very short periods of time. So if we as a group for a day need to kind of let things fall apart so that we can make some really bigchanges before we bring them together tomorrow, I think there's often value in that. But I think if you let [continue] that for more than a day or so,you're asking for a problem.

There's much more! You can find the full interview at dotnetrocks.com/default.aspx?showNum=727.

Richard Campbelland Carl Franklin are the voices and brains behind .NET Rocks! They interview experts to bring you insights into .NET technology and thestate of software development.