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.
-----
BODY:
Let's try this blogging thing in real time.  Steve McConnell,
author of the recent bestseller
<A HREF="http://www.cc2e.com/">
   Code Complete 2</A>,
is giving the opening talk for Day 2 of OOPSLA.  The first
edition of <I>Code Complete</I> 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: <I>Davinci Code Complete</I> and <I>Code Complete:
This Time It's Personal</I>.

The first part of the talk gave several lists summarizing
the software world since <I>Code Complete</I>, 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.

<I> The worst construction ideas of the 1990s</I>

<UL>
<LI> code and fix
<LI> Big Design Up Front  (Back then, it was *all* design up
     front.)
<LI> designing programs based on speculative requirements
<LI> the belief that components will solve all our problems
     (Just as Biddle and Noble's
     <A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-10.html#e2004-10-26T23_08_52.htm">
        postmodernism theme</A>
     tells us, there is no one story that can account for all
     we can or should do.)
<LI> automatic programming
<LI> calling everything "object-oriented"
</UL>

<I>The worst construction ideas of the 2000s, so far</I>

<UL>
<LI> code and fix
<LI> <B>no</B> design up front
<LI> <I>planning</I> to refactor, usually meant as fixing code
<LI> the belief that offshore outsourcing will solve all of our
     problems
<LI> automatic programming
<LI> uninformed use of extreme programming  (An informed use
     of the waterfall approach is likely better uninformed use
     of  extreme programming.)
<LI> calling everything "agile"
</UL>

But not everything in the software world is bad...

<I>A decade of advances in software development</I>

<UL>
<LI> With the theatrical release of <I>The Lord of the Rings</I>,
     all companies now have servers named 'gandalf' and 'frodo'.
<P>
<LI> 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.
<P>
<LI> The daily build and smoke test minimizes integration
     problems and institutionalizes incremental development.
<P>
<LI> There is now accepted, widespread use of standard libraries.
<P>
<LI> 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.
<P>
<LI> open source software
<P>
<LI> the web as a research tool
<P>
<LI> the widespread use of incremental development
<P>
<LI> Test-first design shortens time to defect detection
     and increases personal discipline.
<P>
<LI> Refactoring as a discipline, not as a cop-out, improves
     the design of software.
<P>
<LI> 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
     <I>design level</I>.  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.
</UL>

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:

<UL>
<LI> Construction is a legitimate topic of discussion as an
     activity, a set of practices, separate from the other
     parts of software development.
<P>
<LI> 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.
<P>
<LI> 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
     than written.
<P>
<LI> The toolbox metaphor gives us great power.  We should
     keep that in mind when thinking about our development
     methodologies.
</UL>

Talk Complete.  (That was McConnell's joke, not mine. :-)
-----