January 2006 ISSUE
conference preview
 |
Steve McConnell . . .the go-to guru in the software construction and development industry. |
mcconnell's message unveiled
A leading thinker in the industry of software development and construction will share his knowledge with members, during the 2006 APEGGA Annual Conference Professional Development Days. Steve McConnell is the chief executive officer and chief software engineer for Construx Software in Bellevue, Wash., where he writes books and articles, teaches classes and oversees Construx’s software engineering practices.
Mr. McConnell, presenting April 20 at the conference in Edmonton, is the author of Code Complete and Rapid Development, both winners of Software Development magazine’s Jolt award for outstanding software development books. In 1998 he published the Software Project Survival Guide and in 2004 he published Professional Software Development. Mr. McConnell is a past editor-in-chief of IEEE Software, he is chair of the Institute of Electrical and Electronics Engineering Computer Society Professional Practices Committee, and a member of the Association for Computing Machinery.
Involved in the desktop software industry since 1984, Mr. McConnell has experience in rapid development methodologies, project estimation, software construction practices, performance tuning, system integration and third-party contract management. Noted for his myth-bashing and clear analysis of where the industry is and what it needs to do, Mr. McConnell has a master’s degree in software engineering from Seattle University and a bachelor’s degree from Whitman College in Walla Walla, Wash.
“APEGGA has been grappling with many of the issues surrounding software engineering for some time now,” said Lianne Lefsrud, P.Eng., Assistant Director, Professional Practice. “In fact, a subcommittee of the Practice Standards Committee is just now finalizing our new guideline for software development. So having Steve McConnell discuss professional practice issues members is both relevant and timely.”
Nancy Toth, MA, Manager, Professional Development and Human Resources, is just as excited. “It’s just so satisfying to line someone up with Steve’s profile and reputation. We’re very pleased.”
The PEGG asked Mr. McConnell eight questions about his work and his presentation. Our Q&A follows.
Q. How would you characterize the state of your industry right now? What are its shortcomings, its successes? Where has it been and where is it going?
A. Our industry is like a talented teenage athlete who's strong and has great potential but who hasn't really been tested in the big leagues yet. The software industry has had some amazing accomplishments, but we're still trying to sort out which of our attributes are strengths and which are weaknesses.
Q. When you present to APEGGA members, what will some of your key points be?
A. My overarching point is that software development can be conducted in a systematic way that produces predictable schedules and feature sets, controllable quality, and that doesn't have to balance the project budget on the back of the project team.
The software industry has existed for more than 50 years, and the term “software engineering” is nearing its 40th birthday, so we've accumulated a lot of wisdom about how to develop software effectively. But this knowledge is not nearly as widespread as it needs to be to support truly successful software projects.
I see my mission as taking the good ideas that have been developed by scores of other people and propagating them out to the rank-and-file software development organizations.
Q. Your company’s role is to make sure the art and science of software construction and development mig-rate from the gurus and researchers to the commercial practitioners and technical managers. How’s that coming? Are you seeing the knowledge gap shrink?
A. Yes and no. The best organizations continue to get better. The worst organizations continue not to get better. The organizations in the middle seem to be improving slowly, just through incidental exposure to better development practices. When we're able to work with a company, we see quick improvements.
But we're a small company, and so there are only so many organizations we're able to help directly.
Q. You’ve written what many consider the bible of your industry. How did that happen? Did you intend to be that comprehensive when you started?
A. I started out wanting to write an article on software construction. I assumed that someone would have already written a book on the topic, and so initially I went looking for that book. I spent a couple days doing research in a university library, and at the end of those days I'd collected about 80 papers on software construction — and I'd found that no one had yet written a book on the topic.
That was a surprise to me, because people had already written books on management, requirements, design and testing. The absence of a book on construction — the most central activity in software development — seemed like a gaping hole in the literature.
I spent the next year and a half writing prototype chapters and doing more research. During that time, I had the idea that the book would turn out to be 250-300 pages. That idea wasn't based on any facts or analysis; it was just an assumption. When I got far enough into the project to submit a proposal to a publisher, I created a detailed estimate for the first time and was shocked to see the estimate predict an 800-page book.
I don't know that I would have attempted to write the book if I'd known on day one that it would be as big as it was, but by then I was far enough into the project that I decided to continue.
Q. Our Association, as you know, self-regulates engineering. One of our positions is that software engineering that uses engineering principles must be the province of engineers. Where do you stand on that debate?
A. One of engineers’ key attributes is that they need to have enough breadth to recognize when their work is taking them into an area where they don't have depth. For many years now we've seen a lot of people trained as engineers creating complex, and in some cases safety-critical, software applications — and they don't have enough breadth to know what they don't know.
My position is that engineers who do engineering work need to be qualified to do the kind of work they do. If you have a civil engineer who's built an elaborate computer program to help design bridges, I hope that engineer has more than a self-taught knowledge of software engineering. Similarly, the fact that someone is a skilled software developer doesn't qualify that person to write software for engineering applications.
I think there are two levels of “software engineering.” One is software development that takes place in a traditional engineering context —designing control software for nuclear reactors, embedded software for cars, and so on. This is a level at which I think the “software engineer” should be trained as an engineer in the traditional sense. You might call this “software development in engineering.”
The second level of “software engineering” is software development that does not occur in a traditional engineering context — more mundane applications such as payroll, inventory management, web storefronts and so on. I don't see much reason to train this kind of person as rigorously as the first kind of engineer, but I do see benefits of instilling an engineering mindset in that kind of person. You might call this “an engineering approach to software development.”
The first kind of software engineering is probably of more interest to people who are already engineers. The second kind of software engineering is potentially applicable to a much larger number of people. So both are important.
Q. How critical to the advancement of society and the safety of the public are the proper engineering, construction and development of software?
A. I think the key issue is identifying the appropriate level of rigour for the specific kind of software project. We have some pundits in the industry who want to hold all software to a “zero-defect” standard. I think that's naive. If you understand what it takes to truly get to zero defects, you realize that's not an economically sensible goal for most kinds of software.
Software errors can pose a danger to human life, human safety, economics or just convenience, depending on the kind of software. I think the building industry provides a good analogy for the different levels of software safety.
Some software development is safety critical and complicated, like building a bridge or a skyscraper. You need developers who are the moral equivalent of civil engineers involved in this kind of project.
Some software development is potentially safety critical, like building a house, but the kind of application has been built so many times that you can formalize the rules via a building code or something similar. An experienced general contractor can make the right call in many cases without involving an engineer, even though he or she doesn't have anywhere near the level of training that a civil engineer has.
Then you have the carpenters, riveters and so on who are doing safety-critical work, but the nature of their work doesn't require an engineering background.
Finally, a lot of software development is more like landscaping than like building. It's just moving shrubs and flowers around on the screen until everything looks nice. There isn't any reason to require this kind of software development to adhere to any kind of engineering criteria.
Q. There seem to be quite a few myths out there about software engineering. What are a few of the more persis-tent and troublesome ones?
A. Excessive schedule pressure is a huge problem and the root cause of many other problems. This seems to arise in part because people believe that if they apply schedule pressure, they'll get their software sooner. Usually the opposite is true. It is probably the most persistent problem in the industry.
The idea that there could be one, single approach that works well for all software projects is damaging.
The idea that we don't have to worry about defects in the early stages of a project, and we can just “refactor” our way out of the defects is a prominent problem right now.
Undervaluing effective project management is an issue too. Many software professionals have never seen a project run well, and so they naturally question whether it's possible for a project to be run well.
These are really just the tip of the iceberg. There are so many misconceptions, it's hard to know where to start.
Q. Why do you do what you do? What’s the personal satisfaction here — the thing that gets you up in the morning?
A. My kids get me up in the morning! After that, I just have to decide what to do with my day!
I've felt for a long time that I wanted to do something with my professional life that would make a positive difference in the world. I have a curiosity about what makes things work, and I've found interesting the question of what makes software projects work.
A big part of my personality is that I don't like inflated claims, whether they’re for a new car, toothpaste or software methodology. So what I've written tends to reflect my personal quest for finding the truth about what works and what doesn't, and people seem to respond to that.