A few years back, when my wife and I still had enough free time to do our home remodeling ourselves, we gutted our kitchen and rebuilt it with free-standing kitchen cabinets from IKEA. (For what it’s worth, IKEA kitchen cabinets are surprisingly robust.)

I was recalling this activity earlier today as I reflected upon the flaming waterfall project that I am currently attempting to douse with a steady spray of agile practice and discipline. What would have happened if we would have taken a waterfall approach to our IKEA kitchen?

The high-level design and scoping decisions would have been the same. Basically, we still would have needed to measure and select the right assortment of cabinets to fit in the space and correctly distribute our appliances. But, then, implementation would have been fundamentally different.

Tough as they are, IKEA cabinets still come in flat-pack boxes, and assembly is anything but simple. We worked our way through the cabinets in an iterative fashion. Unpacking all the parts for a single cabinet, reviewing the instruction, assembling the cabinet, then leveling it in place. At the time, I never thought of this as iterative. In retrospect, I realize it was.

Had we waterfalled our kitchen we would have emptied every flatpack box. We then would have confirmed, cabinet by cabinet, whether we had each and every part required for each cabinet. Next, we would have read all the directions for every cabinet, ensuring we had all the tools and skills to build each cabinet. We then we would have assembled all the cabinets in an allen-key-twirling frenzy. And finally, we would have positioned and leveled the cabinets in one fell swoop.

Waterfalling the kitchen would have posed two significant challenges. First, we did not have the physical space to unpack and sort everything without falling over ourselves and–much more serious–mixing different pieces from different cabinets.

Second, since every cabinet was different, surveying all the pieces and reading all the directions in advance would likely have done more to confuse than help us. Only one cabinet needed a hammer, but two others needed a rubber mallet. One cabinet was built from the countertop down. The others from the shell up. The sink cabinet required modifications as we went, since we were repurposing a corner cabinet for that purpose (and we needed additional tools for that). We didn’t need to know all these things in advance. It would have been overwhelming. We needed to know these particulars in context, as we were working on each cabinet.

We even discovered a piece missing from one of the cabinet packs, and it was no simple screw. We discovered it as we were assembling that cabinet and took a fifteen minute trip to the local hardware store (NOT Home Depot) where the owner disappeared into the back and returned five minutes later with a stisfactory substitute part. No upfront review needed; and no arduous trek back to IKEA required.

Now, some will argue that many software development projects are vastly more complicated than my weekend kitchen project. Such statements play exactly to my points above.

First, just as we would have had physical constraints around unpacking and assembling everything in our not-so-small kitchen, software teams have to contend with similar limiting factors. A development team that shifts from an all-encompasing design phase to a full-system buildhas to orchestrate branching and merging strategies, the sharing of test environments, and access to domain and technical experts across the entire system to be built, all at once.

Second, the all-encompassing deign phase (which would have be preceded by a requirements gathering bonanza) fills the team’s heads well beyond the brain’s saturation point with concepts, ideas and hundreds of details critical, trivial and everywhere in-between. When waterfalling into the build phase, you are letting a design-drunk team loose on your codebase. Because they’ve digested and designed everything, they’ve already forgotten significant portions of the system. They’ve likely misplaced and confused requirements and design details across features and components. This only gets worse the bigger and more complicated the system is. You could argue that the team must go back and reread all the requirements and design documentation before they start coding each part of the system, but that certainly sounds like unnecessary rework that most any self-respecting developer will ignore. It’ll all come back, naturally, as they write their code.

Thank God we didn’t waterfall the kitchen. It’s anyone’s guess where the sink would have ended up.