Bridge Building and Software Development

In my last post, I told you about Archie – my bridge for the bridge building contest tomorrow night.  I want to tell you a little bit about my development process for Archie in this post and see if it sounds familiar.

Armed with some basic tools and skills (in woodworking), I set off to build a solution in a new domain (bridge building).  Fortunately, I had some requirements for the new domain.  After some research, I came across a design pattern (the arch) that I thought would work for my problem and decided to make it the focal point of my design.  Identifying the highest risk area of the design (bending the dowel), I prototyped this area until I was satisfied that this could be dealt with in a reasonable manner.

Feeling confident in my design, I procrastinated...  Then, with the clock starting to wind to the deadline, I decided that my prototype was good enough for production.  I built some other pieces and it came time to integrate (put the bridge together).  Integration was a bit challenging and I realized that I needed a new tool (a wood vise) to complete the project.  I also realized that my prototype part was less than perfect (the arches were not symmetrical), but it would have to be good enough.  Shaving a few corners here and there (literally!), I was able to fully integrate the product. 

Now that the product was integrated, I was able to test it against the requirements.  I simulated the production environment (used two VHS tapes set up 12” apart) and verified that the form was correct for my product.  Finally, I gave it a quick stress test (pushed down on the middle of the bridge with my hand) and declared it ready to ship!  Archie will be put into production, albeit very briefly, in the contest tomorrow night.

If you are a software developer, I think the development process should sound awfully familiar if you took out the words in the parenthesis – does it?

When I was formulating this analogy, I initially thought one difference from a typical software project was that I had some well defined requirements for the bridge.  Who can argue with the exact inputs into the solution as well as requirements like “Must span a 12” crevice”?  But as I thought about it, I realized that I had some additional requirements.  The obvious one was that this bridge was supposed to hold the maximum amount of weight while weighing as little as possible.  I also wanted something that was easy to build so that I wouldn’t have to put hours and hours into it.  Finally, I wanted to build something that was a classic design, but also a bridge that would be unique in the competition.  How do I verify those requirements?!?!

Dave Thomas and Andy Hunt (the Pragmatic Programmer guys) wrote a great column for IEEE Software about a year ago called Nurturing Requirements.  In this column, they classify requirements as either ‘constraints’ or ‘wishes’.  The requirements that I was given were the constraints.  If my bridge doesn’t span 12”, it will surely fail.  But I can easily test for that.  The requirements that I added on were my wishes.  Will my bridge design be unique in the competition?  I can’t test that; only time will tell.

So how do you deal with requirements that are wishes from a customer?  Dave and Andy provide some great advice – use iterative techniques, particularly Agile approaches, to give the user feedback on what they are building.  This iterative cycle with customer feedback is core to Scrum, and one of the reasons why it is becoming more and more popular.  The feedback loop shows progress, possibly gives the customer early bits, and forms the basis for further discussion between the developers and the customer.  All that is very cool!

Unfortunately, I have no opportunity to iterate with Archie on my requirement wishes.  As a developer, that doesn’t give me very high confidence that he will do well when the time comes for the true test.  But I will report on that later, after the contest...