Share via

Code Complete 2

The first talk of today was CodeComplete 2 by Steve McConnell. His popular book Code Complete has beed reedited, and he is talking about it, here are my notes about it.

First Version Written in 1993 95% is still OK

 

Book companion WebSite https://cc2e.com/

 

Worst Ideas

 

1990s

 

  • Code & fix
  • Design up-front
  • Design for speculative Requirements
  • Components will solve of your construction problems
  • Automatic Programming
  • Uninformed use of the waterfall model
  • Calling everything Object Oriented

 

2000s

  • Code & fix
  • No design up front programming
  • Planning to refactor later
  • Offshore outsourcing
  • Automatic Programming
  • Uninformed use of XP
  • Calling everything agile

 

Decade Advances

 

  • Ability to create larger code aggregations
  • DailyBuild and smoke test
  • Standard Libraries
  • Visual Basic (case statements are better, biggest code base)
  • Open Source (learn from available code, read code)
  • The web for research
  • Incremental Development
  • Test-First Development
  • Refactoring as Discipline (not so good as total design strategy)
  • Faster computers (forget about performance while writing code, only focus on clearity)

 

Ten realities

 

  • Software Construction. Distinction between Activity and Phases.
  • Individual Variation is significant.
  • Key skills of an expert programmer (Design,, out errors from reqs, coding, naming, reading, unit testing, debugging..)
  • Personal discipline matters (refactoring, prototyping, optimization, minimal complexity)
  • XP requires discipline and courage
  • Simplicity vs Complexity.
  • Why projects fail
    • Focus on read-time not write-time convenience
    • Bad requirments
    • OutOfControl (Too complex code)
    • YAGNI and design for speculative requirments
  • Design is important (Extremes are not productive)
  • Technology waves affect construction
  • Incremental Approaches works best
  • The tool box metaphor (cont to be illuminating)
  • Software essential tensions remain
    • Rigid Plans vs. Improvisation
    • Planning vs. Fortune Teller
    • Creativity vs. Structure
    • Discipline vs. Flexibility
    • Quantity vs. Quality
    • Process vs. Product
    • Optimizing vs. Satisficing

 

Q&A

 

  • Should Doc be in a devs skils?
    • No, the important thing is to memorize important decisions, good code requires few docs
  • Is estimation an important skill for developers? Yes
  • Opinion on Pair Programming
    • Format inspections are better way to find software.

Comments

  • Last updated on