Best of the Shade Tree Developer (with actual links!)

Between being extremely short handed at work, tech' reviewing a new book, a
possible book proposal of my own, and an unsettled situation at work, I'm having a hard
time finding time to create new content for the blog.  So to bide time and
fill a request for a rehash of some of my older posts, here's a "best of"
compendium from the last year and a half.  New stuff will appear soon-ish.

Things I Wished I had Known 3 Years Ago

• 
  Qualities of a Good Unit Test – Bad tests are self defeating
• 
  Using Continuous Integration? Better do the "Check In Dance" –
  Proper build and code hygiene is important, and no one wants to be the "broke the build again" guy.
• 
  Pair Programming Braindump - I hated pairing at first.  Some of us
  have to change our coding habits to make it work.
• 
  Database per Developer and Environment – A lot of people disagreed with
  this, or felt that this was infeasible, but test database contention can
  more or less eliminate the usefulness of automated testing and Continuous
  Integration
• 
  Leaky Abstractions and the Last Responsible Moment for Design – I had a
  reputation (partially earned) at my previous employer for over designing. 
  The most important lesson I've learned over the last three years is how to
  delay technical design decisions until a more appropriate time.
• 
  "Code Complete" is a lie, "Done, done, done" is the truth – This is a
  key lesson to learn if you're going to work in a tightly iterative process.
• 
  Finishing Off Each Iteration with a Deployable Product – See above.
• 
  Ordering Code Construction Tasks
• Creating a Maintainable Software Ecosystem

Test Driven Development

• 
  TDD Design Starter Kit: It’s All about Assigning Responsibilities
• 
  TDD Design Starter Kit – State vs. Interaction Testing
• 
  TDD Design Starter Kit – Dependency Inversion Principle
• 
  TDD Design Starter Kit – Responsibilities, Cohesion, and Coupling
• 
  TDD Design Starter Kit – Static Methods and Singletons May Be Harmful
• 
  Succeed with TDD by designing with TDD
• 
  Unit Testing Business Logic without Tripping Over the Database
• 
  Haacked on TDD and Jeremy's First Rule of TDD
• 
  Jeremy's Second Law of TDD: Push, Don't Pull
• 
  Achieve Better Results by following Jeremy's Third Law of TDD: Test Small
  Before Testing Big – I think this is the most important lesson for
  making TDD work for you
• 
  How much design before unit testing, and how much design knowledge before
  TDD?
• 
  So How do You Introduce TDD into an Organization or Team?

Dependency Injection and Inversion of Control

• 
  Inversion of Control with the Plugin Pattern
• 
  What’s so great about Inversion of Control?
• 
  The Dependency Injection Pattern – What is it and why do I care?

Mock Objects

• 
  Mock Objects and Stubs: The Bottle Brush of TDD
• 
  Why and When to Use Mock Objects
• 
  Best and Worst Practices for Mock Objects
• 
  Mock Objects are your Friend

Design Patterns

• 
  Learning about Design Patterns
• 
  Dynamic Behavior with the Decorator Pattern
• 
  Using the Chain of Responsibility Pattern
• 
  Six Design Patterns to Start With
• 
  The State Pattern: An Underappreciated Pattern

Agile Processes

• 
  Learning Lessons — Can You Make Mistakes at Work?
• 
  Testing Granularity, Feedback Cycles, and Holistic Development
• 
  How Agile practices can help staunch the flow of defects
• 
  Agile Project Management is everybody's job

Testing

• 
  Thinking about Developer and Tester Interaction
• 
  A Taxonomy of Tests
• 
  Create a Testing DSL with FitNesse and Selenium (Part 1)

Bending Legacy Code to my Will

• 
  Legacy Code and the Life and Death of an Application
• 
  Balancing Technical Improvements versus New Business Features
• 
  Environment Tests and Self-Diagnosing Configuration (with StructureMap)
  - This has helped us tremendously with our legacy code
• 
  Lessons Learned for Dealing with Legacy Code

Random

• 
  Long Methods and Classes Are Evil
• 
  Architect: Person, Role, or Useless Appendage?
• 
  Use a refactoring checklist to pay down Technical Debt as you work –
  Little refactorings applied immediately are the ounce of prevention that
  keeps a ton of rewrite away
• 
  The Importance of Being Explicit
• 
  Classic Technical Lead Blunder- Been there, done that
• 
  It's just not enough to be right…