Steve McConnell Keynote

Today I attended the opening keynote for the SD West 2004 Conference
featuring Steve McConnell:
“Code Complete 2: A Decade of Advances in Software Construction.” I last heard Steve speak two years ago at SD2002. His speaking
style matches his books which are full of practical advice for software developers. Following are my notes from his talk.

Code Complete, 2nd Edition

Will be released June 1, 2004. His original mission for Code Complete (CC1) was to
capture lasting knowledge of software construction. He’s asserted for many years that 95% of the content is still relevant.

Scope for CC2:

  • Formally inspected entire first edition
  • Approx. 500 programming examples updated to modern languages
  • New chapters
  • OO & web integrated throughout
  • Numerous online resources (cc2e.com)

Underlying Distinction behind the CC books:

  • Technology knowledge: readily acquired, short lived
  • Principles knowledge: Not so readily acquired, longer lived

Overview of talk

  • The worst construction ideas of the 1990s and 2000s
  • A decade of advances in software construction
  • Ten realities of modern software construction

Worst Construction Ideas from 1990s

  • Code & fix
  • “All design up front” programming
  • Design for speculative requirements
  • Components will solve all our construction problems
  • Automatic programming
  • Uninformed use of the waterfall model
  • Calling everything “object oriented”

Worst Construction Ideas from 2000s

  • Code & fix
  • “No design up front” programming
  • Planning to refactor later
  • Offshore outsourcing will solve all our construction problems
  • Automatic programming
  • Uninformed use of Extreme Programming
  • Calling everything “agile”

A Decade of Advances in Software Construction

  1. Design has been raised to a new level

    • Ability to create larger code aggregations statements, routines, classes, packages
    • Real legacy of OO might well be larger aggregations
  2. Daily build and smoke test

    • Institutionalizes incremental integration
    • Minimizes serious integration problems that used to be common
    • Lots of other benefits, too
  3. Standard Libraries

    • Good programmers have always used libraries
    • Now provided with languages (Java, C++, .NET)
  4. Visual Basic

    • Visual programming innovation
    • First development environment to make widespread use of COTS components
    • Only language to learn Ada’s syntax lessons (case statements, control statements, etc.)
    • Highly integrated environment
  5. Open Source Software

    • Great aid to programmers during development
    • Reduced barriers to making code available
    • Opportunity to learn from available code
    • Improved ability to *read* code
    • Nice “community” of programmers
  6. The Web, for Research

    • FAQs
    • Discussion groups
    • Search ability in general
  7. Widespread Use of Incremental Development

    • Concepts well known in 1990s
    • Practice is well established in 2000s
  8. Test-First Development

    • Shortens time to defect detection
    • Increases personal discipline
    • Complements daily build & smoke test
  9. Refactoring as a Discipline

    • Provides a discipline for making changes (not so good as a total design strategy)
    • Good example of incrementalism
  10. Faster Computers
    • Compare CC1 performance benchmarks to CC2 benchmarks
    • Implications for optimization
    • Implications for programming languages
    • Implications for development

Ten Realities of Modern Software Construction

  1. “Construction” is a Legitimate Topic

    • Activity != Phase (distinction between activities and phases)
    • Talking about Construction as an activity does not imply a distinct phase
    • Differentiating between kinds of activities is extremely helpful
  2. Individual Variation is Significant
    Researches found variation anywhere from 10x to 28x in:

    • Coding speed
    • Debugging speed
    • Defect-finding speed
    • Percentage of defects found
    • Bad-fix injection rate
    • Design quality
    • Amount of code generated from a design
    • Etc.

    Key Skills of Expert Programmer

    • Designing
    • Flushing out errors & ambiguities in requirements
    • Coding (naming, formatting, commenting)
    • Reading & reviewing code
    • Integration
    • Debugging
    • Unit testing
    • Teamwork
    • Using tools for all of the above
  3. Personal Discipline Matters

    • Being realistic about predicting the future
    • Areas where discipline matters
      • Refactoring
      • Prototyping
      • Optimization
      • Minimal-complexity designs specifically
      • Managing complexity generally
    • Endpoints — Discipline and Courage
    • Humphrey on PSP, Beck on Extreme Programming
    • A focus on simplicity works better than focus on complexity
  4. Why do projects fail?
    • Focus on read-time convenience, not write-time convenience
    • YAGNI and design for speculative requirements
  5. Defect-Cost Increase is Alive and Well

    • Average cost to correct still increases over time
  6. Design Remains Important
    Design Advice — What has changed in 10 years?

    • In 1990s, design pundits wanted to dot every i and cross every t before writing any code
    • In 2000s, say BDUF (big design up front)? YAGNI (you aren’t gonna need it)
    • There are lots of valid points on the no design–all design continuum

    Extremes are usually not productive

    • All design up front vs. no
    • Entirely planned vs. improvised
    • Pure iterative vs. straight sequential
    • All structure vs. all creative
    • Document everything vs. nothing
  7. Technology Waves Affect Construction

    • Definition of technology wave
    • Construction is affected by technology — more than I thought
    • Technology can be addressed in terms of general principles
  8. Incremental Approaches work Best
    Perspective on incrementalism

    • Pure waterfall model is not at all incremental or iterative–which is why it hasn’t worked very well
    • Spiral development is highly incremental and iterative, which is part of why it does work well
    • All projects will experience iteration at some point
    • Think about where and when in your project you will get your incrementalism — cheaply, or expensively?
  9. The Toolbox Metaphor Continues to be Illuminating

    • What’s best? Agile? XP? Scrum? DSDM? CMM?
    • Toolbox explains there’s no one right tool for every job
    • Different industry segments will have different tools and even different toolboxes
    • What’s in the Software Engineering Toolbox?
      • Best practices
      • Lifecycle models
      • Templates, checklists, patterns, examples
      • Software tools
  10. Software Essential Tensions
    • Unchanged for years
      • Rigid plans vs. improvisation
      • Planning vs. fortune telling
      • Creativity vs. structure
      • Discipline vs. flexibility
      • Quantitative vs. qualitative
      • Process vs. product
      • Optimizing vs. satisfycing
    • Balance wavers, but basic tensions are constants