|
By: Jorg Largent
Young students in junior high school provide an interesting laboratory to observe architecting without the bells and whistles of large quantities of money and without the sophistication of complicated and advanced technologies. - The setting: twenty students attending a one-week “engineering camp” in the summer.
- The challenge: win a contest hurling a Ping-Pong ball the farthest. They had only a few classroom hours to solve the problem — the competition was the next day.
- The task: form teams of two and build a catapult with the materials provided.
The materials provided to each team were paper, sheets of balsa wood, balsa dowels, a mouse trap, and an assortment of rubber bands, plus glue, knives, and saws – supplies such as one might find in a hobby shop, save the mouse trap.
They’re Off! All of the teams, with one exception, were drawn to the mousetrap in their supplies. The mousetraps were not simply “fancy” in terms of their relative mechanical complexity; the bait pad on the mousetrap was a bright yellow, whereas everything else was a drab, beige color. Setting and triggering the mousetrap became a major activity, especially since a mentor was the one who got his finger caught (and he was glad it was not a rattrap). They settled on the mousetrap as the source of the kinetic energy for the ball.
The teams made this architectural decision somewhat independently of the adults and the other teams; their decisions were based on the attributes of resources provided, and their understandings of catapults. The team that was an exception had different under standing of catapults, and chose to use the mousetrap only as a base for a design that used the rubber bands as their energy source – a design somewhat akin to a medieval catapult.
Fly-Fix-Fly. The individual efforts shifted to wondering what the other teams were doing. As a consequence, the architecture of the designs, except for the medieval catapult, started to look the same. This phenomenon was influenced by what worked. One challenge the students found was that the mousetrap moved when triggered. The teacher added the importance of consistency from one shot to the next. The teams quickly got into a cycle of trying to figure out how to make the mousetrap stay in place, guessing, making modifications, looking at what the other students were doing, and testing the new product. The medieval catapult team had a similar problem and started sneaking a peek or two at the more pedestrian designs. The teams quickly learned that direction was not a requirement, but, due to the layout of the “test range” (a wide aisle along the side of the shop), there was a directional stability requirement derived from the testability requirement.
Postflight Debrief. The students were asked to describe their experiences and what happened. Without using the terminology of systems engineering, they made several points, all of which should be familiar to the veteran in the real world. There were limitations, which impacted their design and the architecture of their system. They were limited by the materials provided. They were limited by the tools and their ability to use them (one nicked finger). They were limited by the workspace. They were limited by schedule in that they ran out of time. The time limitation was particularly the lament of the team trying to build the fancy, scaled-down version of a medieval catapult.
When asked why not just throw the Ping-Pong ball, they had no answer beyond thinking they were obliged to use the materials provided as a part of winning the contest. Besides, just throwing the ball seemed too simple. They overlooked an obvious point: the “materials provided” included themselves. An Aside from Which We All Can Learn. Later in the week the students were taught to design using a program on the computers in the lab. The program had limitations, and the students learned that the program was no match for their imaginations: their designs were limited by the tool.
In the Real World of Six-Figure Salaries, So What? There are lessons to be learned about both architecting and requirements development in this discourse. - Architecture and requirements development are interwoven.
- Neither architecture nor requirements are a starting point; in this case the challenge was to win the contest. The starting point was a mission statement. For these students the mission statement was to hurl a Ping-Pong ball further than any of the other teams. This mission statement was not formalized, but it was clearly understood. An aside: “clearly understood” versus “fraught with soaring rhetoric” is an important attribute of a mission statement.
- A concept of operations and consequential functional analysis are essential parts of the process, be they formal or informal.
- Keep it simple. The most elaborate design did not fare well. The simplest solution – just throw the ball – would have been the winner, but it was not attempted.
- Don’t overlook the obvious.
- “Attractive,” as in the color, action, and the exciting potential risk of a pinched finger associated with the mousetrap, or “attractive,” as in a pitch from marketing, is a poor and limiting basis for architecture.
- Not all requirements are known at the beginning; hence, derived requirements. The students learned that resources, producibility, and testability were sources of requirements that influenced their design.
- Presumed knowledge from before the project and sneaking a peek at the competition are of limited worth in that they can help solve a problem more quickly, but, at the same time, they can prevent consideration of a more appropriate solution. A corollary is the trap of what one of our colleagues has called “pet rock technology” being pursued by a strong-willed advocate.
- There are constraints such as resources, time, and capabilities. These are in addition to the occasionally overlooked laws of physics.
- Some constraints or limitations are voluntary but unnecessary, as they are the consequence of things such as poor tool selection.
The activities above and the points they illustrate are common to the real world. There is wisdom to be gleaned from the adventures of these young students. Increasing the complexity of the system, the number of requirements, and the sophistication of the technology may well increase the need for formality, but it does not negate what there is to be learned from this scaled-down version of what is done in the “real world.” |