Indy Code Camp Notes, Part 1

This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.

These notes are in no way intended to replace attending one of these talks if you have the chance.

Care About Your Craft: Adventures in the Art of Software Development

Presented by: Tim Wingfield – Quick Solutions

Tim’s talk focused on how to get better results out of each phase of the SDLC. Included here are key points from each section.


  • TDD should not be thought of only as Test Driven Development but also as Test Driven Design
  • Design with the SOLID Principles in mind
    • Single Responsibility Principle
    • Open/Closed Principle
    • Liskov Substitution Principle
    • Interface Segregation Principle
    • Dependency Inversion Principle
  • Design by Contract – TDD can actually force us to do this
  • Avoid programming by coincidence – Understand how and why something works
  • Don’t be a plumber – Chances are good that someone else has had to save the same technical problem so there might already be a framework that can be used and let you focus on the actual business problem at hand
  • Justify technology use – Don’t use a technology just because it’s new, use it because it better solves the problem
  • You Ain’t Gonna Need It (YAGNI)
    • Don’t waste time building features that might be used


  • Quality is not an accident – build it into everything starting with requirements
  • Don’t Repeat Yourself (DRY)
    • Reuse code and avoid copy/paste programming
  • Automate where ever possible
    • Build servers are a great for automation
    • Use code generators to speed up development by automating common coding tasks such as creating properties, creating method stubs, and refactoring.
  • Avoid finger pointing by taking collective ownership – We’re all in it together
    • OUR build broke
    • OUR defect
  • Don’t live with broken windows
    • Bad code begets bad code
    • Fix problems when they’re found (time permitting) rather than letting them propagate
  • Know when enough is enough
    • Perfect is nice but software has to ship sometime


  • Someone (QA or a customer) will find a defect
  • When a defect is found, don’t panic
  • Think about the solution before rushing to action
  • Avoid placing the blame and work toward the best solution

Continuous Improvement

  • Always keep learning
  • Maintain a positive attitude
  • Be a mentor
  • Create a culture geared toward continuous improvement
    • Schedule lunch ‘n’ learns
    • Have book reviews