Editor's Note: Welcome to .NET Rocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show 727, with Steve McConnell, author of several software development books, software engineering maven, and CEO and chief software engineer at Construx Software. Steve, Richard, and Carl converse on a range of subjects -- from executives' role in software development projects to the role of Agile and Scrum 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 progression of books that I've written, Code Complete obviously started out very detailed, very in-depth, the workers in the trenches who were actually doing the 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 the meantime, 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 software development.
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 other way 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-on software 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 say doesn'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 project managers… 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 or VP-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 comes time 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 directed enough 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 letting people 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 did they 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 my books 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 to 100 percent have some software background. I could certainly name some exceptions, but that's probably 90 percent to 95 percent software development background.
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 has just 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 or 1,000 people, I think it becomes very difficult if not impossible for those people to maintain the technical chops that maybe got them promoted much earlier 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 fact that 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 them for 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 but also really push on better documentation or better understanding of the project or better training. I think often, especially at the development level, we just 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, really facilitating 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 of managers level or VP level is really pretty undefined in most organizations. I like the elements that you defined trying to free up technical staff to really 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 sure the 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 job description 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 "Code Complete 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 mostly assumed 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 table and say, "Hey, we should be talking about the detailed ins and outs of coding and debugging and unit testing and [how] these detailed construction activities 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 on trying to engage customers via the working software, and so on…. And then, the first couple of years of the Agile movement was extreme programming focusing on test-driven development and coding standards and pair programming, really activities and practices focused at the code level extended the emphasis that I 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 Complete in 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 were using, 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 things are 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 to make 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 changed all 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 still reasonably 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 think when 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-level technique 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. I think 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 in ascendancy 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 Scrum emerge 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 more challenging. 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 think some 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 that 100-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 pretty significant 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 if they'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 integration these 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's happened 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 via Martin Fowler, and at the time continuous integration really meant continuous, meaning you save the file and everything would be recompiled in the background 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 look at 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 the expectation that individual developers would build only daily. The expectation was that the project would build at least daily and individual developers would 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 to build 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 letting the 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 big changes 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 Campbell and Carl Franklin are the voices and brains behind .NET Rocks! They interview experts to bring you insights into .NET technology and the state of software development.
- Email: Richard
- .NET Rocks!: http://www.dotnetrocks.com/
