Practices

Kalamazoo X Sessions

The organizers of the Kalamazoo X Conference recently posted the session and speaker list.  All of the sessions sound interesting but the ones that have really grabbed my interest are:

I’ve previously attended two of Mike Wood’s presentations (one at Indy Code Camp and an nPlus1 event in Indianapolis) and really get a lot from them.  He has posted a series of articles about being a better developer that I admittedly haven’t read yet but will probably do so before April 10th.

I was also fortunate enough to hear Phil Japikse speak about Behavior Driven Development at the March IndyNDA meeting.  He shared tons of great information about methodologies and tools and I’m really looking forward to hearing more of his thoughts on testing.

I was really excited about this conference based on what I’d heard about last year’s event.  After seeing the session list I’m glad I registered.

Advertisements

IndyTechFest

Last year I made the mistake of missing IndyTechFest.  That’s not a mistake I care to repeat and one I certainly will not be making this year since my registration is already confirmed.

This year’s event includes forty sessions broken out into seven tracks.  The sessions are of interest to developers, architects, and DBAs and include topics such as Silverlight, WPF, Visual Studio, Windows and SQL Azure, Windows Phone 7 Series, Database Maintenance, SharePoint, Iron Ruby, and many, many more.  The list of speakers is equally impressive and is topped off with a keynote from Jesse Liberty, a Developer Community Program Manager for Silverlight.

Registration is limited to 500 attendees and with more than 400 spaces already spoken for time is running out!

I hope to see you there.

SOLID Principles

Today was nPlus1‘s sixth ever architecture summit.  This summit was held in Indianapolis, IN and addressed the SOLID principles.  The presenters were Mike Wood and Dan Rigsby.

The SOLID principles were originally defined by Robert Martin as a set of guidelines for writing better code.  As with any guidelines, these are not steadfast rules that must always be followed but proper application of these principles can make code more maintainable, flexible, and readable.  There is a plethora of information about these principles so rather than going into detail about each of them this article just includes a brief description of each one.

One argument against using some of these principles is that following them will result in more code.  Some may argue that having more classes and interfaces will ultimately make the system too difficult to understand.  The counterpoint to these arguments is that there are no more moving parts in a system with many small pieces than a system with a few large ones.  That is, if it’s doing the same thing it should be no more or less difficult to understand.  The trade-off to more code is a system that is more accepting of change when (not if) it comes.

Additional Resources

They Write the Right Stuff

A few days ago someone on Reddit linked to this fastcompany article about the team responsible for building the space shuttle’s on-board software. The main focus of the article is how this team of 260 people consistently releases virtually bug-free software.

This article was really timely for me given some of the Code Camp sessions I attended last weekend. Many of the key points from those sessions were reiterated for me.

Although most of us don’t write software that is not only used in but also controls life and death situations, we as a practitioners of a maturing industry could really benefit by studying and incorporating their practices. The article is a bit long but really worth the read.

Indy Code Camp Notes, Part 4

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.

Test Driven is Driving Me Insane!

Presented By: Dennis Burton

Dennis’s talk focused on road-blocks to effective Test Driven Development and some common, practical test patterns. My notes are a little sparse on this one since it was the last session of the day and my mind was wandering a bit ;) He had a lot of good examples that I wish I could remember a bit better.

Road-blocks To Effective Up-front Testing

  • Management push-back
    • “Double the code? Are you kidding?!”
    • Project timeline impact due to code changes taking longer while tests are updated
  • Test design issues
    • Long-running tests – ideally each test should run in less than a second
    • Long-setup time
    • Fragile tests – more work is required to keep tests running when changes are made
    • Data dependency issues – tests rely heavily on data specific data, often from a production environment

Common Patterns

  • Dummy Pattern – use when an object is needed only to help construct another object
  • Stub Pattern – use when an object is needed to help construct another object and its state must be verified
  • Mock Pattern – use when testing functionality functionality instead of specific data
  • Spy Pattern – use to add validation to an object that does not implement the required validation. This is typically implemented as a wrapper class that passes values into the type being tested

Recommendations

Indy Code Camp Notes, Part 3

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.

Being More Than a Code Monkey: Practicing Beautiful Code

Presented By: Michael Wood – Strategic Data Systems

In this session Michael described some common traits of “ugly” code and presented some guidelines as to what makes code beautiful. Clean Code by Bob Martin is recommended reading for more information on this topic.

Beautiful Code is NOT

  • Hard to follow
  • Hard to extend
  • Something you have to slog through
  • Done with brute force (If it’s really hard to do you’re probably doing it wrong)
  • Code that people run from

Why Should I Care?

  • Working with ugly code can negatively impact project timelines. If code is difficult to understand it will take subsequent developers longer to get to a position to maintain that code. It can also potentially have cross-project impact if previous developers need to be brought in to help explain the code.
  • Code that is difficult to extend will likely require additional refactoring which can possibly seep into additional areas.
  • Like broken windows bad code tends to beget bad code. High quality standards need to be maintained consistently across the application in order to be effective.

Traits of Beautiful Code

  • Self documenting – types and their members should be named according to their purpose. Comments are nice but need to be maintained to be effective as code is changed. By writing self-documenting code the need for comments is significantly reduced if not eliminated.
  • Avoids using magic numbers – anything that could be a magic number should be defined as constant or enum member. Similarly, consider using an abstract class with constant strings to simulate an enum to avoid having hard-coded strings inline.
  • Exceptions carry additional information – the Exception class has a Message property and an InnerException property…USE THEM!

Code Monkey Song by Jonathan Coulton

Michael mentioned this song and video in his presentation so I thought I’d include it. Enjoy!

Indy Code Camp Notes, Part 2

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.

Improving Our Craft: A Discussion on Software Estimation

Presented By: Michael Eaton – Validus Solutions

Michael started his talk by tossing out some statistics about project success rates and defining some terms. He then moved on to discussing why we’re so bad at giving good estimates and wrapped up with some ideas for how to improve the estimates we do give. Unfortunately I wasn’t able to capture the exact stats but they were eye-opening to say the least in that in 2006, only 32% of projects were considered to be successful.

Terms

  • Estimate
    • Tentative evaluation or rough calculation
    • Preliminary calculation of cost
    • Initial judgement
  • Target
    • Statement of desirable objective
  • Commitment
    • A promise to deliver

Understanding Estimates

  • The challenge is to determine whether we are supposed to be estimating or projecting to hit a target. If we’re projecting to hit a target do we produce what was expected?
  • Estimates will by their nature, be wrong. We’re providing estimates not exactimates.
  • A good estimate is one that provides a clear enough view of the project reality to allow the project leadership to make good decisions regarding targets.

Why Are We So Bad?

  • Unknown problem domain
  • Vague, missing, or large requirements
  • We forget stuff
  • Overconfidence
  • Insufficient education or practice making estimates
  • Never given a chance to succeed (set-up for failure)

The Cone of Uncertainty

The Cone of Uncertainty states that the actual duration of a project can take up to four times as long or 1/4 as long as expected.

What Can We Do?

  • Stop giving off-the-cuff estimates
  • Communicate
  • Incorporate Agile practices
    • Iterations
    • Daily Stand-ups
  • Decompose the problem into smaller chunks and estimate the chunks
  • Let developers estimate their own tasks rather than having a manager or lead developer provide estimates for the team
  • Estimate end-to-end tasks
  • Learn from your mistakes
  • Keep a log of estimates and periodically review it