Natural Order Development

Just had a reason to open up my code archives. Not a big deal, just checkout the older stuff from the Subversion archives and add some new Eclipse projects.

Lions, tigers and bears oh my. What the heck are all those warnings!?

LOL one of the things I started doing a few years back was to start worrying about TDD and code complexity. Somewhere in the last couple of years I added the metrics plugin for Eclipse (http://eclipse-metrics.sourceforge.net/). Which is very nice since it supports complexity checking using a number of different metrics:

• McCabe's Cyclomatic Complexity
  
• Efferent Couplings
  
• Lack of Cohesion in Methods
  
• Lines Of Code in Method
  
• Number Of Fields
  
• Number Of Levels
  
• Number Of Locals In Scope
  
• Number Of Parameters
  
• Number Of Statements
  
• Weighted Methods Per Class

Sometimes you really should let the past remain the past. I had such fond memories of all these cool and wonderful applications and utilities I wrote years ago at the beginnings of Java. Yet here I was looking at them using the latest Eclipse with all the TDD and metrics warning thumbscrews in place (to keep me honestly doing what I preach) having to view my own legacy code.

This will make far me less critical of other legacy code I have to clean up from now on. Yes, my legacy applications still compiled, they still worked. But code coverage is zero, cyclomatic complexity is up in the 50s for most of my methods (in the hundreds for the control points) and oh my do I really have methods over 200 lines long! This is a very humbling experience.

If you'll excuse me I need to sweep the dirt off the floor, dust the corners and polish the brass in my own legacy code.

Been dealing a lot of SCRUM items and it seems to me that a lot of teams keep missing the mark because of not clear "done criteria". For the record I think a minimum done criteria is:

• Code is checked-in into a central version control system
  
• A detailed code review (including comparison to any company and/or team coding standards) has been complete, any suggested changes implemented and final code has been checked-in
  
• Unit tests with demonstratable cover coverage of more 80% for non-integration / "out of container"
  
• Automated Integration Coverage (AIC) or Fit / FitNess integration tests are written with code coverage more than 80% (aka "in container")
  
• Exploratory manual testing by someone other then the developer has been complete with no open defects
  
• Some kind of profiling (a la JProfiler) has been complete on the developer's system and results are documented in release notes
  
• Release notes and/or usage documentation has been written (and in the appropriate place)

The team needs to keep these items in mind when estimating any backlog, unless these items are complete, the backlog item should not be called done. Of course there are more done criteria specifying the story or behavior requirements which are the responsibility of the product owner to provide (and the team to question heavily on.)

I always love a good laugh and this one is great. The developers and testers at Google have put up a great "How to Write 3v1L, Untestable Code" article with tongue in cheek and enough sarcasm to really tickle your thought processes. In reality is a list of things not to do as a developer. I love the reverse style delivery. You can find the complete post here: Google Testing Blog (http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-code.html).