John Hines' Software Process Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  39 Posts | 6 Stories | 43 Comments | 0 Trackbacks


The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud

Article Categories


Image Galleries


Friday, October 2, 2009 #

There's a recent blog post that was sent to me in response to my insistence on Test-Driven Development:

"The Duct Tape Programmer" by Joel Spolsky.

The gist of the post is: Good programmers ship software.  I agree.  And my response is: Great programmers ship quality software.

When I wrote commercial software, there were no unit tests.  All testing in-house was done by some internal QA testers, and if the software passed smoke tests it was sent through a full test run.  This could take a week or more.  The schedule was King.

When I wrote code part-time and did full-time Active Directory management, there were no unit tests.  I didn't have time.  I had a full time job, a rotation on the help desk, new tools to write and old tools to fix.  My workload was my boss.

So if you're in the situation where just finishing is a victory, more power to you.  But don't settle there and take a fanboy post to mean you never need to bother with TDD or testing in general.  It could be that you constantly check in timely, buggy code that everyone else hates while simultaneously patting yourself on the back for your Duct Tapey-ness.

Today I'm developing tools full-time to be used inside of the company.  There are two huge differences between intranet software development and commercial programming: Deadlines are more flexible and there is no QA department.  You wrote it, you support it.  For life.

Adopting Test-Driven Development and Scrum has been a survival mechanism for us.  It's the reason my three person team (including myself) can support sixteen production apps.  We don't dare ship bugs, our entire roadmap crashes when we have to rework.

So all I'm trying to say is that you can have your cake and eat it too.  You can have good quality software that you ship quickly - just keep it as simple as possible, build quality into the process, and finish the thing.


In a big company there are often dozens, if not hundreds of projects going on at the same time.  Getting stuck on a bad one - one that's disorganized, frustrating, and sure to forget any contribution you make (no matter how major) - is a pretty common occurrence.  Disengaging yourself skillfully becomes a kind of art form.

My team reached its limit recently after being assigned to a poorly run project for three months.  As a parting gift, we gave lots of advice on how the project should be run - not 20% Scrum/80% Chaos, but 100% Scrum.  The accountable manager then had his team define project had goals, milestones, a short-term schedule, and yes, a daily stand-up meeting.

The result?  Just as my team is preparing to disengage, we find we're suddenly quite busy!  The daily scrum has done some impressive things.  It has:

  1. Shown the real team.  The people who really aren't committed don't bother to come to a brief, daily meeting.  It's very clear who the people doing the work are.
  2. Increased collaboration.  The area experts have become known, and people ask them questions.
  3. Sped the project.  Issues that would have delayed people for days are now resolved much faster.

Not bad for a meeting that lasts no more than fifteen minutes.  You still need those other things - goals, milestones, and schedules.  But if you want an effective project team using Scrum, don't skip the daily stand up meeting.

Technorati tags: Scrum Scrum Process