TITLE: Steve McConnell on the Realities of Software Construction
AUTHOR: Eugene Wallingford
DATE: October 27, 2004 1:11 PM
DESC: McConnell opens Day 2 at OOPSLA 2004 by talking about what software development is really like -- and how it has changed since his popular 1993 book.
Let's try this blogging thing in real time. Steve McConnell,
author of the recent bestseller
Code Complete 2,
is giving the opening talk for Day 2 of OOPSLA. The first
edition of Code Complete is a classic in the field,
still cited by software engineers and practitioners.
McConnell opened with some humor on the hazards of renaming
a book called 'complete'. The best ones played off cultural
icons: Davinci Code Complete and Code Complete:
This Time It's Personal.
The first part of the talk gave several lists summarizing
the software world since Code Complete, the prequel,
came out. A lot of the humor and insight in these lists
lay in how some items showed up multiple times, or in how
opposites showed up.
The worst construction ideas of the 1990s
The worst construction ideas of the 2000s, so far
- code and fix
- Big Design Up Front (Back then, it was *all* design up
- designing programs based on speculative requirements
- the belief that components will solve all our problems
(Just as Biddle and Noble's
tells us, there is no one story that can account for all
we can or should do.)
- automatic programming
- calling everything "object-oriented"
But not everything in the software world is bad...
A decade of advances in software development
- code and fix
- no design up front
- planning to refactor, usually meant as fixing code
- the belief that offshore outsourcing will solve all of our
- automatic programming
- uninformed use of extreme programming (An informed use
of the waterfall approach is likely better uninformed use
of extreme programming.)
- calling everything "agile"
I'm not going to report all of McConnell's ten realities of
modern software construction, but I will summarize some of
the points that struck me:
- With the theatrical release of The Lord of the Rings,
all companies now have servers named 'gandalf' and 'frodo'.
- We now do design at a higher level. Indeed, this may be
the ultimate legacy of OO: we design our systems in terms
of larger aggregations or abstractions.
- The daily build and smoke test minimizes integration
problems and institutionalizes incremental development.
- There is now accepted, widespread use of standard libraries.
- The creation of VisualBasic has brought several advances to
common use in the public: visual programming, widespread
use of COTS components, and improved control constructs
that learned from Ada language design principles.
- open source software
- the web as a research tool
- the widespread use of incremental development
- Test-first design shortens time to defect detection
and increases personal discipline.
- Refactoring as a discipline, not as a cop-out, improves
the design of software.
- Faster computers have radically changed how we have to
think about software development. Computers are so much
faster than they used to be (McConnell spoke of having to
perform test code 5 million times just to get measurable
results!) that we should no longer think about optimization
at the code level. It is almost never worth the effort.
We can now pay attention to optimization primarily at the
design level. Machine speed also means that we can
use languages that we like, that make us more productive,
without having to worry about the speed of interpreters,
compilers, and compiled code.
Talk Complete. (That was McConnell's joke, not mine. :-)
- Construction is a legitimate topic of discussion as an
activity, a set of practices, separate from the other
parts of software development.
- Personal discipline matters -- in the form of making
realistic predictions, refactoring code, and creating
simple designs. McConnell didn't mention writing tests,
but I think it belongs here, too. He did point out
that, while many folks think of Ward Humphrey and
Kent Beck as representing very different sorts of
software methodology, perhaps at opposite ends of
a continuum, the discipline of Humphrey's PSP and the
courage of Kent's XP are in much the same spirit. I
think that this is a great insight. XP is not high
ceremony, but it is high discipline. I once asked
Kent what one new practice I should introduce into my
first-year courses, and he said, "Have your students
keep a project notebook", so that students could record
their behaviors and be able to examine and improve
them. Not so much different than PSP.
- The fundamental tension in software is between simplicity
and complexity. In the trade-off between write-time
convenience and read-time convenience, the former is worth
essentially nothing, given how much more code is read
- The toolbox metaphor gives us great power. We should
keep that in mind when thinking about our development