Building Myself a Kayak: Some Lessons for Requirements and Software Engineering
Olly in Skin-on-Frame Kayak
Gotel, O. Building Myself a Kayak: Some Lessons for Requirements and Software Engineering Part I. In Requirements Quarterly 53, The Newsletter of the British Computer Society Requirements Engineering Specialist Group (RESG), January 2010, pp.7–13.
Gotel, O. Building Myself a Kayak: Some Lessons for Requirements and Software Engineering Part II. Requirements Quarterly 54, The Newsletter of the British Computer Society Requirements Engineering Specialist Group (RESG), April 2010, pp.6–11.
During the summer of 2009, I decided to build myself a skin on frame Qajaq (kayak). Being a complete kayaking fanatic, I wanted to learn more about the history of the kayak 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.
‘Qajaq’ (pronounced ‘kayak’) is the traditional Inuit term used to refer to a Greenlandic skin on frame kayak. For ease of reading, I shall use ‘kayak’ throughout this article.
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
Figure 1. The Story Stick for a kayak is always close to hand (it is the stick on the floor close to the hand!)
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 chines.
The reader is directed to a number of online glossaries at the end of this article. These define all the terms that are used in this article, more precisely. The chines are two long pieces of wood that define the edge of the kayak, from the side of the kayak (the gunwale) to the bottom (the keel), thereby providing its hull shape.
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
Figure 2. The traditional language of the Inuit kayak
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.
(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
Figure 3. Clear markings for fixing and cutting
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.
How do we indicate to others where we want task attention to be focused when we engineer requirements and software? It is somewhat tricky to mark-up the artifact of interest itself, in the hope that the required action will be noticed and undertaken as anticipated. Instead, we maintain associated project plans and create tickets for work, and we attempt to describe what needs to be done and where within these. The addition of ever more fragmented written artifacts, encodings of our intentions, leads to growing coordination and communication issues across teams and over time. This then sets up a challenge for subsequent traceability. In requirements and software engineering, we need a better way to juxtapose process information with our product for communication and recording purposes.
4. Proceed from an architectural backbone
Figure 4. Shaping the gunwales using windlasses to hold their position
With a kayak, all the woodwork required to build the frame is completed prior to the skinning (Note that fabric is mostly used nowadays to skin a kayak, not seal skin! This is usually a heavy-grade nylon). The first woodworking task was to join the gunwales, the two long pieces of wood that form the port and starboard sides of the kayak, to mark the midpoint of both, then to pull them apart to define the desired shape of the overall kayak. This shape was retained temporarily using a number of windlasses, as shown in Figure 4. There are three fundamental shapes for the kayak: neutral, where the maximum breadth of the kayak is at the midpoint, making the kayak symmetrical; fish-form, where the widest point is in front of the midpoint; and Swede-form, where the widest point is behind the midpoint. This decision determines the distribution of the kayak’s volume. Although the eventual completed frame may resemble the bones of a fish, the backbone of the kayak is not the keel at the bottom of the kayak, but it is these very important gunwales. These provide the kayak with strength, and a solid basis to build upon and attach further wood to. Once these are in place, work can proceed.
In software engineering, requirements could be said to be the backbone of the system, since the end result is likely to be unsatisfactory if these are found wanting. However, we rarely elucidate and articulate the core requirements upon which all the others depend, let alone experiment with options for the shape they could take before proceeding with all those that follow. As per the gunwales, the core structure may be framed by non-functional properties, such as the overall shape and strength required of the system. It is all too easy to build on shifting sand, in our attempts to consider either every possible requirement upfront, or to accommodate any requirement that arises later. In requirements and software engineering, we need to differentiate those requirements upon which others depend. We need to do this far more concertedly, early on in the process, and create an architecture that allows other requirements to emerge later.
5. Envision prior to any commitment
Figure 5. Working out the positioning of the keel before drilling
Progress appeared to be extremely rapid at the onset of the workshop, as pieces of wood were assembled into something that resembled a kayak in one day. There was then a visible sign of progress with every subsequent day, although less pronounced in the second week. This ability to see a kayak materialising kept people motivated and positive. The use of clamps made it possible to attach pieces of wood to each other to experiment with positioning and shaping, prior to any permanent change or attachment. This enabled a three-dimensional view of the envisioned kayak at every step of the way, visibility that was indispensible for fixing deck beams and ribs to the gunwales, positioning the keel and chines, and for finalising the profile of the hull, bow and stern before commitment. The ability to experiment with the keel position is shown in Figure 5.
It is useful to be able to see the impact of decisions before they take hold. We attempt to do this in software and requirements engineering with rapid prototyping and user interface design mock-ups, but we rarely see beyond a two-dimensional surface or gain a view of the bigger picture. In particular areas, like change impact analysis, our ability to pre-visualise the impact of change prior to commitment, both locally and systemically, would be invaluable from a cost perspective. However, we perceive many of our actions to be reversible, so we sometimes forget the cost that rework incurs. In requirements and software engineering, we need ways to visualise the intentions and likely outcomes of our abstract intangible work.
6. Measure twice, cut once… revisited
Figure 6. Preparing to make that cut
The Carpenter’s Maxim is well known and quoted in software engineering circles. As suggested by Figure 6, wood once cut stays cut. When it comes to kayak building, not only is this maxim imperative, it actually goes much further than this. We did measure more than once before cutting any wood. More important, we used different strategies and techniques to achieve any one measure. The trickiest task for me was placing the chines on the kayak because, when I took two different approaches to measurement, I kept coming up with two different results for their placement. It was the only way to catch that I was doing something wrong.
It is not an exaggeration to say that requirements and software engineers rarely think about measurement. When they do, they cling to one of a few well-known metrics and use those as a basis for decisions. In requirements and software engineering, we really ought to take a multi-pronged approach to how we obtain our measurements, particularly if we are to gain confidence in our measures and advance as a true engineering discipline.
7. Stabilise to localise change and care for what remains
Figure 7. Stabilising the frame to work on a stem piece
Whether sawing, drilling or planing, we always ensured that the kayak was stable so that we could work on a specific area without causing a negative impact on the rest of the kayak. Throughout the entire building process, it was important to ensure that the wooden frame rested on two saw horses (or more) as we worked on specific areas, as shown in Figure 7. This was to maintain the frame’s overall integrity and to prevent sagging as pressure was applied to areas. When sawing, we learned to hold the piece of wood that was to remain, rather than the piece of wood that was to be disposed of. When fixing, we would clamp the join for a number of hours to hold the wood in position until the glue had set.
We do a reasonable job in requirements and software engineering when it comes to change management, particularly when working on versions of documents or code with a team of people. However, given that it can be quite tricky to understand all the hidden or emergent interrelations in an abstract system of this nature, assuring stabilisation of the whole as changes are made and take effect is not a trivial matter. The perceived ability to rollback any changes to a previous state, as mentioned earlier, is a belief that sometimes leads to a lack of initial care and attention with initial modularisation. In requirements and software engineering, we need to focus on this proactively when structuring requirements and the designs that flow from them.
8. Work within acceptable tolerances
Figure 8. Checking those tolerances again
Small mistakes propagate in kayak building and the impact accumulates. For example, if the ribs are positioned slightly off of the original marks when drilled and dowelled, you may find that you can no longer lash the ribs to the gunwales as securely as desired. To minimise the impact of errors, you need to decide what will be acceptable tolerances early on. Whenever we measured anything (see Figure 8), everything was acceptable to 1/16th of an inch and we learned to work within this margin of error. The consequence of every small deviation becomes even more critical, however, as the kayak nears completion. When it was time to attach the final stem pieces to the bow and the stern of my kayak, I was too terrified to do the drilling, as a slight mishap in the drill angle would have meant redoing a lot of work. When undertaking critical tasks nearing completion of the build, the master kayak builder played a critical handholding role for the under-confident.
Do we make sufficient allowance for inevitable human error when we engineer software? We have approaches to help us detect, address and tolerate errors. We also have strategies to prevent errors in the first place, if we do a good job at requirements engineering. However, do we pay sufficient attention to all the small innocuous deviations that can eventually add up, or do we focus mostly on the larger and more obvious failure modes? Do we know what our acceptable tolerances are for everything we do and work within them? In requirements and software engineering, we should begin to understand the acceptable tolerances for different tasks and try to work within them.
9. Avoid single points of failure and unnecessary rework
Figure 9. Dowels and lashings to secure each deck beam
The reliability of a kayak relies upon engineering multiple back-ups in the final product. For example, the integrity of the wooden frame is secured in three ways: using wooden dowels and glue for a primary attachment of wood to wood; lashing wood to wood for a secondary attachment; and tensioning the skin around the final frame for a tertiary. The first two levels of this system are shown in Figure 9. Kayak building also requires pre-planning if you are to avoid having to do work over. For instance, you need to plan for the attachment of float bags and put the deck lines in place before closing up the skin, else you have a nasty cutting and additional sewing job to do later.
When engineering software, it is common to have to undertake much rework; refactoring is an acceptable term these days. With a physical structure such as a kayak, rework is incredibly difficult, frustrating and costly in time. As such, it demands anticipation and thinking ahead from the kayak builder, continuously reflecting on what is required in the eventual end product and understanding what needs to be put in place in the present to enable this to happen with ease. It does not mean doing all the requirements upfront, but it does mean understanding the overall concept early on and not flying blind into the build. Pre-emption is a precursor to gaining resiliency in most forms of engineering. In requirements and software engineering, we need to start to share more information on rework efforts and failures across projects, especially if we are to avoid learning the same painful lessons over and over.
10. Employ models and create informal sketches where useful
Figure 10. Bending wood around a cockpit template to form a coaming
At the start of the workshop, we made use of a reusable wooden rig to simulate sitting in a kayak, in order to get a feel for the required dimensions of the cockpit (e.g., length and width) and to assist with the positioning of critical deck beams. This would ensure that we would be able to slide in and out of our kayaks once completed without removing our kneecaps. When it came to forming the cockpit itself, we selected a prior cockpit coaming template to refine to our own dimensions. These would be used to bend wood to form our own individual cockpits, as shown in Figure 10. The role of a model or template is clear in kayak design and, once used, it is set aside. Throughout the entire kayak building process, impromptu sketches on scrap pieces of wood were also used for the communication of concepts and techniques, and to support decision-making tasks. For example, a two-dimensional matrix was sketched out on wood (resembling a ‘Go’ board) to help seat the ribs evenly, while the performance characteristics of differing hull shapes were sketched as needed to help with difficult chine positioning decisions.
Requirements and software engineering is all about modelling, and we reuse prior patterns in our design and coding activities with some regularity. However, we tend to call anything a model, so the line between what is the model and what is the final product can get quite blurred. As a consequence, the role of the model may mutate beyond its intended role and its planned useful life may be extended unwisely. Our use of informal sketching in requirements engineering is also still quite limited, even though sketching makes for a natural way to express tentative ideas and concepts early on amongst non-specialist stakeholders. In requirements and software engineering, we need to clean up our modelling practices and also look at how we can exploit much simpler means of informal communication.
11. Understand the role and value of the expert
Figure 11. Our experts, Turner Wilson and Cheri Perry (Photo from Kayak Ways, used with permission)
The entire kayak building process would have been a complete disaster without the oversight of an expert eye. In our case, these were the four expert eyes of Figure 11. Our master kayak builder was able to see things that the rest of us overlooked or simply missed, moving seamlessly from the most intricate detail to the overall line of the kayak, across all five kayaks in parallel. The expert was also able to troubleshoot and improvise fixes to all our disasters, from poorly drilled holes, dowels popping out of wood, severed lashings, to split ribs. Continuous quality control and endless resourcefulness was achieved thanks to years of accumulated knowledge. The critical role of the expert even came into play long before the workshop began, in selecting the raw materials. Shamefully, I was unable to discern oak from cedar at the start of the workshop, let alone differentiate viable rib stock for bending from that with bad grain. I am proud to say that I am far savvier with wood now! With an expert on hand, we learned that there are very few points of irrevocable disaster. With an expert on hand, we had the confidence to try things out.
One of the best ways to learn any engineering discipline is to apprentice with a master, and this is indeed what we did with our kayaks. Having the opportunity to learn about failure modes, and to witness the tactics derived to mitigate these first hand, provides for a deeper level of understanding than simply repeating activities and getting everything right the first time. In requirements and software engineering, we rarely have the opportunity to work so closely with such an individual. This is problematic to do, not only because the majority of the work that we do is solitary, abstract and intangible in nature, but also because there is not always a single individual with all the requisite skills and necessary patience. Instead, we tend to be thrown into the deep end. Our own mistakes are not always so immediately visible either. Many software-related errors are left for others to find and fix in the deployed future. Furthermore, when the inexperienced are left to procure core platforms and technologies to support a new software development venture, the shortcoming may never be overcome. In requirements and software engineering, we need to revisit the way in which we teach and train, and we need a way to identify those inspiring master builders.
12. Know the most precious resource and the most ubiquitous
Figure 12. You can never have too many clamps
The bandsaw was the most indispensible tool for all the kayak builders in the workshop; its reliability lay on the critical path for each of us as it was used to pre-cut the wood to approximate size. However, the bandsaw malfunctioned early on in the workshop and was subsequently unreliable. We further exhausted all the replacement parts for it. Thus, work on the critical path stopped for everyone as acquiring new parts became a lengthy off-island experience for one person. The most used item in all of our kayaks was dowels and we exhausted our supply twice. Running out of dowels therefore led to another hold up in operations. Clamps were both precious and needed in large quantities, and these were the one item that we had in abundance, since emphasised in the kayak building literature. When building a kayak, you can never have too many dowels, clamps or back-up bandsaw blades (see Figure 12 to appreciate why).
In requirements and software engineering, we tend to think of our key resources as people and money, and indeed they probably are. But, skilled people and money are prerequisites to do most things in life. A reliable inventory of traceable requirements, moreover, can be considered precious in software development and is something that we therefore need to maintain. Requirements drive the critical path of what we design and build. Traceability helps these requirements change as we learn more about them and facilitates confirmation of their eventual satisfaction. As to the most used resource in requirements and software engineering, it is possibly the myriad of channels that we rely on for communication, but generally take for granted. We often do not pay as much attention to planning for softer skills and team working needs, as perhaps we should. In requirements and software engineering, there are many critical resources that we neglect and need to pay far more attention to.
13. Use the right tool for the job
Figure 13. Lashing made easy using a curved needle
While it was possible to use a small number of tools when building our kayaks, life was made far easier when the right tool for the particular job was used. The difference in size and angle of the plane that was used could make a task last either ten minutes or take two hours. A metal rasp could equally halve the time of a sandpapering task. A hot knife would seal the cut edges of the fabric at the same time as it was cut, thereby completing two tasks in one. Curved sewing needles would make a directional pull of thread around difficult wooden corners both feasible and easy, as evident in Figure 13. The smart kayak builder not only has a well-equipped boathouse and toolbox, but knows exactly what to use and when, and they can interchange between the use of these tools seamlessly.
On reading a draft of this article, one of the kayak builders (Eben) remarked on how he has always been fascinated by the power of tools to increase the equivalent skill level of a person: “With a workshop full of tools we novices were able to produce a complex hunting craft equivalent to what an expert using just a hook knife and bow drill could make.” Being a professional software engineer, he also drew the parallel: “With the right IDEs (Integrated Development Environments) and function libraries an average developer can create and debug complex systems like database and web apps.”
The large majority of tools in requirements and software engineering are general purpose and require considerable knowledge and tailoring to exploit fully. While there are also tools dedicated to niche techniques and tasks, they can often be difficult to use in concert, or it is prohibitively expensive to do so. More critically, there may be little that is transferrable from one tool to another by way of technique, so the value in taking the time to learn the tool could be debatable. Given that the learning curve for tool use can be high, and the longevity of the acquired skill uncertain, we naturally resign ourselves to the use of the few tools that we own and know. Our relationship with tools is also quite different from that of a kayak builder’s – do we keep our tools organised, neat, sharp and ready-to-hand? In requirements and software engineering, a collection of smaller and simpler tools may be the way to go, but only if we can get back to the essential underlying techniques that we need.
14. Master the underlying techniques to capitalise upon use of the tool
Figure 14. Mastering that planing technique
It is not sufficient simply to have a collection of different sized chisels or planes in your toolbox. You need to learn the technique of chiselling or planing if use of any one of these tools is to be effective. As suggested in Figure 14, this is only achieved through practice on the job. Even the way you swing a simple hammer, either with or without gravity assistance, is going to impact how well and how easily it works in practice, irrespective of its size or your strength. Some activities we repeated over and over during the workshop, and we began to master the techniques with practice, such as sawing, dowelling and lashing. Other techniques would obviously take a few more kayak-building experiences, like mastering the transfer of angles with a sliding bevel and intricate spokeshave manoeuvres.
In software engineering, we sometimes do not distinguish the technique from the tool, assuming that we will acquire any necessary technique through use of the tool. This is a notable issue when it comes to requirements management tools. Do we really know what the fundamental techniques are that we need to learn and master to capitalise upon use of our tools? We can name the underlying techniques in the kayak-building world, but in the software world they tend to be somewhat vague and large in their scope: elicit requirements, specify requirements, code, test, etc. Also, where and how do we pick up these skills? This is on the job and under the watchful eye of a master kayak builder when learning to use the tool in the kayak world but, in the software world, we are often expected to make the transfer to a practical setting from the classroom on our own. Many of our tools are so overwhelming and so feature rich that we never quite get to become fully competent in the core underlying techniques that matter, the techniques that will serve us best in the longer term. In requirements and software engineering, we need to highlight the foundational and transferrable techniques of the discipline if we are to focus on them more overtly.
15. Embrace diversity and pull together
Figure 15. We may not all be skilled at carving, but we can share skills
Although each of us in the workshop was learning all the skills that we needed to build our own kayaks, some of us were naturally more talented at some tasks than others. I was considered a good lasher and seamstress, so I was able to trade the application of these skills for intricate carving or drilling tasks on my own kayak by others, two things that I certainly did not master. Eben carved the shark bow piece for my kayak that is shown in Figure 15 (For someone who spends so much time on and in the ocean, I still have a great fear of sharks – I blame it all on reading and watching ‘Jaws’ when I was way too young. This bow piece is my talisman). While much can be done individually, some tasks do work better in pairs, such as having an extra eye to help maintain an angle whilst drilling, while some tasks require a whole team, such as four people to steam wood, then bend and affix the resulting ribs quickly. Given the nature of the workshop, as a joint learning experience, we all needed to stay somewhat in step in our kayak building schedules to make it manageable. So, when one person fell behind, we would all pull together at the end of the day to ensure alignment. We all wanted everyone to succeed in his or her own work.
It was once accepted in requirements and software engineering that individuals would specialise in particular areas and work together as an integrated product team to leverage complementary skills. More recently with the agile movement, the idea has become that individuals should be able to undertake any task in the software development process, any one member of the team being replaceable if the knowledge and skills are circulated continuously within the team. Competence and skill in all areas takes time to master though and we cannot always all be acknowledged experts at everything. What if all the team members are at the beginning of their skill learning curves? In requirements and software engineering, we need to take care in resourcing our projects to blend the competencies and personalities of individuals, while nurturing their individual career aspirations, rather than simply expecting people to be autonomous cogs in jobs.
16. Provide for a healthy and safe working environment
Figure 16. Maintaining a tidy work environment
In a woodworking environment, there can be a lot of dust and noise when many people are sawing, drilling and hammering all day long. Protecting eyes and ears is critical, as is ensuring adequate ventilation and light. Equally important is ensuring that people are alert and aware around any machinery, and so they need to be well nourished and work at a sustainable pace. We were fortunate to have a team of fantastic cooks on hand who made sure that we had lots of refreshment breaks, often outside on the dock. We also listened to music to help some of us focus, while ongoing chatter about kayaks and paddling kept others fully immersed in the process. Where there was idle time, as some people had completed tasks before others, such time was used to sweep and clean the boathouse, collect and tidy tools, and to ensure the retention of a workable environment. A tidy moment is captured in Figure 16. We were not just workers doing a job; we were enthusiastic apprentices keen to learn and share, passionate about the product we were building and we wanted to enjoy the process in every way possible.
Health and safety issues are not so easy to identify when it comes to the work of requirements and software engineers. Nevertheless, endless days of computer usage, poor posture and flood lighting can all take their toll. The idea of refreshments often only extends to pizza and caffeine in our world. It is consequently common for individuals and teams to reach burnout as deadlines arise. While some enlightened workplaces focus on ergonomics and comfort for their employees, imagine what a team of requirements and software engineers could accomplish with an in-house chef cooking up delights and forcing imposed downtime in natural surroundings! Also, imagine the commitment if the team had some future stake in the ongoing use and success of what they are each creating. In requirements and software engineering, we need to prepare and tend to our working environments much more carefully if we are to demand excellence from our engineers.
17. Recognise that the best is the enemy of the good
Figure 17. There is no time to fuss about when working the steam box
For the first five days of the workshop, I wanted everything to be perfect. I even smoothed out rough edges on wood that would remain hidden inside my kayak and created a thumb nook to help me get into my kayak (which, to date, I have never used). With some non-critical measures, rough approximations using fingers were wholly sufficient as a heuristic, but I would insist on lining everything up and using my tape measure to be absolutely precise. As time passed, I realised that I was sweating the small stuff too much and needed to compromise on perfection if I was to finish on time. It was the 7:00am to 2:00am work day on day six (yes, I really did work for about seventeen hours that day, once all the enforced meal breaks had been factored in), when steaming, bending and fixing the ribs for my kayak (as a team, at top speed and still falling behind), which led to this epiphany (Figure 17).
When we undertake requirements and software engineering activities, we rarely have any benchmarks to judge how efficiently and effectively we are working. Most of our estimates are arbitrary and individual productively, for one, can be a controversial thing to measure. Also, many projects do not start with a clear understanding of what it takes to be considered ‘done’, so we keep on with many activities long past the point of return on investment. It is essential to have a prioritised set of requirements and accompanying acceptance tests to ensure that we focus on what matters most and, in the interests of a wider schedule, know when it is time to move on. In requirements and software engineering, a perfectionist can be as hazardous as a negligent, so we need to learn how to recognise what is ‘good enough’.
18. Watch that urge for closure
Figure 18. Waiting for the waterproofing to dry (Note that the horizontal wood is the keel, chine and gunwale as you look down the upside-down kayak)
Come the final days of the woodworking, I just wanted my kayak frame to be finished. All the care and attention that I had put into the previous days could easily have been wiped out with a careless slip of the drill. The trigger for the change in my behaviour was the realisation that I was not going to be completed in the two weeks I had expected, so I would not be taking my kayak home to New York City with me. None of us would be finished and we would all have to return to Maine later in the summer to skin our kayaks. The reasons are explained later and mostly come down to the environment (the Maine weather). At the time, I thought that I could speed things up and skin my kayak before the waterproofing was dry, just so the process would all be over in the one visit. Although waiting was painful, as the inactivity of Figure 18 shows, the alternative would have been detrimental. On my return visit to Maine, I was concerned that something else would go wrong and require a third visit, so I sewed up the skin at top speed on my arrival. I then desperately wanted to get the skin painted before the caulk sealant had dried, so that the paint would have a chance of drying before my scheduled departure. That would have been detrimental too, so I waited. The problem was that I could see my kayak emerging in front of my eyes. All I wanted to do was to take it home, get it on the water and paddle it before the summer was over. I did not want to chance nature again. As luck would have it, we had a glorious sunny painting and drying day, and we all took our finished kayaks home after the second trip north. Patience is so much harder to muster when the end is in sight, but yet so far from attainment. It is consequently the easiest time to introduce that irreversible disaster. This is the one time when the advice of the expert is the most invaluable, even though it can be very hard to digest at the time.
In software engineering, the time when activity seems to peak on a project is when the reality of a deadline draws near. It is the time when a bug is fixed hastily, thereby introducing far more new bugs, and when other corners are cut to ship a product. This is exacerbated with an abstract intangible product like software – who can see that omission or shortcut? Irrespective of how or why this happens, it is the time in the process when more quality checks and balances than usual need to be imposed. In requirements and software engineering, if any part of a software project is to be scrutinised more than the initial requirements, it is the activities of those final hours.
19. Conduct early testing and a final fairing
Figure 19. Testing it fits before taking the next step
At many points during the workshop, we could actually sit in our wooden frames to check the dimensions and fit of our kayaks, as illustrated in Figure 19. One person even dropped his frame on the concrete floor of the boathouse to check that it would not fall apart. It didn’t. We all undertook our own forms of idiosyncratic testing along the way, to convince ourselves that the kayaks we were building would actually fit, because they all looked so very small. However, we never once tested that they would float, so we took the primary requirement for any kayak completely on trust. We also never tested out their likely behaviour ahead of time to see whether they would perform as expected on the water. We relied on sketches and trusted the opinions of our experts. Prior to the skinning, we all conducted what is called a ‘final fairing’. This is a careful look over the shape of the kayak, and a smoothing of all the rough wooden edges, to assure the eventual profile and silhouette once skinned. Any lashings needed to be seated into bevelled wood to permit for a non-lumpy skin to avoid drag in the water. We focused entirely on testing the form and fit; we relied entirely on expert judgement for all the rest.
In software engineering, we unit test fragments of code with some regularity, though we often tend to leave the overall functional testing of the assembly towards the end of the process. Early user testing is possible when we work with customers and end-users during the requirements activities, but we sometimes forget to continue to do this as the software evolves and as time becomes pressing. It is obviously easier to do all forms of testing when the product you are building is for yourself and when it is in your hands, literally. However, the idea of a final fairing applied to requirements and software engineering is an appealing one, ensuring a final check over all aspects prior to points of commitment. We attempt to do this with inspections, but we do this neither routinely nor rigorously. If only we could judge how a set of requirements would behave by standing back and simply looking at them from different angles. In requirements and software engineering, we are beginning to bring testing to the forefront, but we still have plenty of scope to make this practice integral to the forward engineering process every step of the way.
20. Determine the risks and have a back-up plan
Figure 20. One of those rare good weather days in Maine
There were certain time windows that we needed to adhere to if we were to finish building our kayaks in two weeks. After the first few days, we were on schedule, and then things slipped. It became evident that our most valuable resource, the bandsaw, was compromised. More critically, the damp Maine weather meant that everything took twice as long to dry than expected, quite the problem when the first level of integrity of the kayak frame is provided through glued wooden dowels. The Maine weather that we had counted upon is shown in Figure 20, but we only got that kind of weather maybe three days out of the two weeks. As a result, we experienced delays and only finished the wooden frames on the original visit, despite working twelve to seventeen hours every day (these long working days were only possible for the reasons discussed in 16). We returned to Maine to skin the frames six weeks later over a long weekend. On that trip, we had glorious sun.
Not finishing a project on time, with the functionality as initially anticipated, is accepted as the norm in software engineering. Risk identification and mitigation strategies can help us build in better contingency to project plans but, to some degree, we cannot anticipate everything and control the natural environment. If we did not accept some risk, we would never get to start on engineering anything, so we learn to proceed with acceptable risk. Time criticality is perhaps what really sets software engineering apart from kayak building. Deliver late and you may blow a contract or miss a market, and consequently do not get paid or lose a business. With my kayak building, there would always be another day for my indulgence. In requirements and software engineering, irrespective of the best project planning and risk assessment, perhaps we too can blame the weather sometimes?
In Closing…
Figure 21. My kayak and me, together at last!
My rolling kayak was worth waiting for and well worth building right. Yes, it floats, and the evidence of this is given in Figure 21! It also fits me like a pair of trousers and I can roll it like a whirling dervish when in the water. Not only did I plan, design and build something that required hard physical labour (hard for me that is), as well as acquire many new skills, I gained a wider appreciation for why it is necessary to apprentice with an expert when learning any engineering-related craft. The value of such an experience is further magnified when you can observe and learn from other apprentices who are going through the same process with you.
The technical world of requirements and software engineering is far removed from that of traditional Inuit kayak building. I would not even begin to claim that they are comparable in their complexity, as every now and again we see software systems that are engineered that stretch the bounds of the imagination. However, the kayak building process is engineering in the most classical sense, and it is a tradition that has survived and been passed on through the generations in Greenland. In going through the learning process myself, I decided that the requirements for a personal kayak are quite easy to determine once you get to the heart of what you actually want and why. Getting to pare down to those essentials however, in a world of endless possibilities and dreams, is the really hard part to do. I got what I really wanted ONLY by letting go of what I did not really need. That was a critical insight for me.
Figure 21. My kayak and me, together at last!
However, I probably could not have undertaken this exercise had I not been a pretty advanced kayaker. The trade-offs that I made and the precision that I required only made sense because I felt them, personally. We are rarely experts in the domains that we create our requirements and software for, but apprenticing to learn about the product domain is as essential to our success as apprenticing to master the engineering process. But even as domain experts, we certainly could not have built a single kayak to suit all five of us at the workshop. The problem of achieving an agreed set of requirements amongst a set of stakeholders was blatantly clear in this context. This issue remains one of the largest and underappreciated challenges of software requirements engineering; the only way in which this is sometimes possible is to build a software system that has compromised the requirements away.
Most importantly, we could not have evolved our requirements, and then satisfied them in our kayak designs and builds, without our kayak master builder’s hard earned, tried-and-tested experience being passed on to us every step of the way. I therefore urge all requirements and software engineers to experience being an engineering apprentice in this same spirit. Build something that you have always dreamed of, but lacked the know-how and skills to do. You will gain a wider appreciation for why we, in requirements and software engineering, have such a long way left to go in understanding the nuances of our own engineering discipline and in passing on our craft to others. You never know, your reflections may help us all as we proceed on this important journey, and you might even have some fun!
Acknowledgements
My special thanks go to Turner Wilson and Cheri Perry of Kayak Ways for making this kayak-building workshop such a memorable engineering experience for me! It was a real joy to see such a skilled and passionate pair of kayakers selflessly enabling others to pursue their own kayak building dreams. As a pair, Turner is the kayak master builder of this article, while Cheri is one of the best Greenland-style kayak rollers in the world.
The workshop would not have been such great fun if it had not been for my four fellow kayak builders: Dave, Eben, Bob and Geoff. I learned so much from each of them and their contributions are all now part of my aptly named ‘Shark Attack’ kayak. Thanks to Dave and Eben for taking the photos that were used in this article and, given they are both IT professionals, for suggesting connections between kayak building and software development that I had overlooked. I also thank Eben for making his wonderful waterfront boathouse in Vinalhaven our home for the workshop. I particularly thank Ali, Elise and Patsy for making sure that the workshop felt more like a luxurious gourmet eating vacation than the extremely hard work that it actually was!!!
Finally, my mum read and commented on early versions of this article, under some duress! While she is a keen kayaker, she is a reluctant user of technology and she has never quite understood what I do for a living. Not only does she now have a vague idea about requirements and software engineering, she also ensured that I did not veer off into a technical reverie and stuck to using Plain English! I also thank Ian Alexander and Simon Hutton of the RESG (Requirements Engineering Specialist Group of the British Computer Society) for their insightful comments and their enthusiasm to see my musings shared in RQ (Requirements Quarterly).
Glossary
Kayak and maritime terms used in this article
Bow, Chine, Cockpit, Coaming, Deck Beam, Deck Lines, Final Fairing, Float Bags, Gunwale, Hull, Inuit, Isserfik, Keel, Lashing, Masik, Port, Qajaq, Rib, Rocker, Roll, Skin, Skin-on-frame, Starboard, Stem Piece, Stern, Track.
See Qajaq USA Audio Glossary for qajaq terms and Andrews Maritime Terms.
Woodworking terms used in this article
Bandsaw, Chamfer, Chisel, Clamp, Dowel, Drill, Hammer, Hot Knife, Japanese Pull Saw, Plane, Rasp, Sandpaper, Saw, Saw Horse, Sliding Bevel, Spokeshave, Story Stick, Windlass.
See Word Working History glossary.
For Further Reading
- Cunningham, Christopher. Building the Greenland Kayak: A Manual for Its Construction and Use. Camden, Maine: Ragged Mountain Press, 2003.
- Dyson, George B. The Aleutian Kayak. Scientific American Magazine, Volume 282, Issue 4, April 2000.
- Golden, Harvey. Kayaks of Greenland: The History and Development of the Greenlandic Hunting Kayak, 1600–2000. Portland, Oregon: White House Grocery Press, 2006.
- Morris, Robert. Building Skin-on-Frame Boats. Hartley and Marks, 2001.
- Peterson, H. C. Instruction in Kayak Building. Nuuk: The Greenland National Museum and Archives and Atuakkiorfik/Greenland Publishers, 2001.
- Qajaq USA. The American Chapter of the Greenland Kayak Association.
- Zimmerly, David W. An Illustrated Glossary of Kayak Terminology. Canadian Museums Association Gazette, Volume 9, Issue 2, 1976 (Can be downloaded from his extensive Annotated Bibliography of Arctic Kayaks).