Building Myself a Kayak: Some Lessons for Requirements and Software Engineering (Part I)

During the summer of 2009, I decided to build myself a skin on frame kayak. Being a complete kayaking fanatic, I wanted to learn more about the history of the kayak1 and to understand how design decisions impact a kayak’s behaviour on the water. What better way to do this than to go through the process of building a traditional Inuit kayak for myself? Having absolutely no practical skills, it was clear that I was going to have to learn to do this in a workshop setting under the watchful eye of a master kayak builder.

With my master kayak builder located, along with a very appealing workshop location (a waterfront boathouse on the island of Vinalhaven in Maine), I received a list of required tools. Given that I was clueless about woodworking tools, this was obviously going to be an interesting shopping experience for me. What is a Japanese pull saw exactly? What is a spokeshave used for? Does it matter if I get a plane that is not low angle? I was probably the first person to request photos of all tools. After having borrowed everything possible from friends, and having raided almost every hardware store in New York City, I finally packed up my bag of tools and headed off to coastal Maine.

In the weeks leading up to the workshop, I had been thinking long and hard about the kind of kayak I wanted to build, only to realise that I did not really know. I knew that I valued fit, comfort and aesthetics, so much so that I took these things for granted. I also simply assumed that my kayak would float and be water tight, so I gave that no thought at all. However, I wanted my kayak to be fast and to track well (so it had to be long and narrow), to be an excellent roller (so it had to be low volume and sit low in the water), and to be able to handle rough water, waves and wind (so it had to be short enough to turn easily and have some rocker on its waterline for manoeuvring). These three things were, of course, all in conflict. I wanted to build myself the multi-purpose kayak that excelled at everything … and, as I jumped on an airplane to go north for two weeks, I thought I could actually do it!

Day one of the workshop was my wake-up call. Along with four fellow kayak builders, we discussed what we each wanted to build with our master kayak builder. Did I really want to build a compromise kayak, a kayak that would never be good at any one thing? No, but I could not decide what to prioritise. I was asked to think about what I actually wanted to do with my kayak above all else and most of the time. It was at this point that I realised that I was about to embark on a requirements engineering journey. I therefore decided that I should see if I could learn a few lessons for the day job as I sawed and drilled my way through the next couple of weeks. To cut a long story short, I decided that I would build myself a rolling kayak. Rather than take you step-by- step through my internal requirements negotiation, and kayak design and building process, I have compiled a list of my top twenty observations from my efforts, and I draw some simple lessons for requirements and software engineering from them.

1. Rip a Story Stick to serve as a baseline

On day one of the workshop, we each ripped ourselves a ‘Story Stick’. A Story Stick is a long piece of off-cut wood that acts as a reference point throughout the entire kayak building process (as shown in Figure 1). It is used to record all the key measurements of an individual in one physical place, such as their wingspan (i.e., the tip of one middle finger to the other with outstretched arms) and their cubit (i.e., the tip of the elbow to the tip of the middle finger), measures that translate to important dimensions of the kayak so that it is custom built to fit. You start with the Story Stick measures that you design to and then, so long as you comply with these key dimensions, you can make ongoing design decisions every step of the way. In fact, it is somewhat possible to shape the characteristics and behaviour of the kayak as far as 90% into the woodworking portion of the build, the critical point of no return being the placement of the chines2.

The Story Stick for a kayak is always close to hand (it is the stick on the floor close to the hand!).

We have been struggling with the process of requirements discovery ever since the dawn of software engineering. Our approaches range from attempting to specify all the requirements upfront (i.e., Waterfall) through to incrementally adding requirements stories as they arise (i.e., Agile). In the kayak-building world, we take a middle way. We work towards an overarching goal (e.g., a functional rolling kayak) and identify key measurements to then work within as we decompose and realise this goal. We neither make all the decisions upfront nor add features arbitrarily as and when they arise in our minds. We proceed along a truly incremental path that is governed by a few key constraints. In requirements and software engineering, we still need to find our middle way.

2. Agree Terminology

We used traditional Inuit and maritime terms to refer to all aspects of the kayak, so we knew exactly which part of a kayak we were referring to at any one time. When there are multiple deck beams and ribs in a wooden frame, it is important to have a scheme to refer to each beam and rib uniquely and precisely. For instance, the first deck beam in front of the cockpit is called the Masik and the first deck beam behind the cockpit is called the Isserfik. The traditional Inuit kayak terms are shown in Figure 2. The same rigour was applied to the tools and techniques we used. For example, if we were instructed to chamfer the wood, we knew we were to put a 45-degree angle on to the edge to take out a square corner. We were hence able to understand what parts of a kayak were being discussed and what techniques were required in any group instruction or communication. We were therefore also able to work on each other’s kayaks interchangeably and as needed.

The traditional language of the Inuit kayak (Please visit the Image Map of Shawn Baker and Craig Bumgarner to hear the terms spoken and to view their English translations)

In requirements and software engineering circles, we still debate the meaning of fundamental terms. Does requirements management refer simply to the management of requirements once specified or to all the activities of requirements engineering (i.e., elicitation, analysis, negotiation, specification, management, etc.)? When we ask someone to validate a requirement, do they verify instead? Are we able to use agreed terms to refer to the internal contents of a requirements specification or to the component parts of a software system? Use of agreed terminology facilitates the conduct of any complex task that involves more than one person. In requirements and software engineering, we need to go back to basics and agree on our terms.

3. Make marks consistently

The manner in which a pencil is held affects the angle and width at which a line is drawn. This can have quite dramatic consequences if a sawing task is soon to follow. I learned that there is a ‘proper’ way to sharpen a pencil to get a crisp line. I also learned that there is a ‘right’ way to hold a pencil against wood to draw this line in a repeatable way. There is a need to be consistent in how marks are made in woodworking for reliable results. The marks remaining from newly cut wood are shown in Figure 3, along with the conventions for deck beam and rib positioning on the gunwales. Where multiple lines or thick lines are visible on wood, and where these cannot be erased completely, standard conventions are then used for indicating where exactly to cut.

Share Button

Leave a Reply