Kitchen Remodeling as Computation

I once had an opportunity to observe a kitchen remodel from start to finish, interacting with the general contractor who was heading up the remodel along the way.  And I must say, if you consider yourself to be a competent contractor or handyman and are looking for a career change, all I can say is...consider computer science.

In my limited sample of one well-executed kitchen remodel, I submit that the knowledge and skill set that makes one excel in managing a kitchen remodel are not so different from those required to excel in computer science.  While the generated artifacts are different — cabinets, plumbing, and countertops as opposed to applications, data structures, and algorithms — the thought processes and mindsets toward making high-quality versions of these artifacts are very similar in the two endeavors.  Heck, the term “architecture” is meaningful, and even congruent, in both areas.  That’s got to count for something, right?

As the contractor walked me through what he was doing — start with setting appliances aside, demolish the old kitchen, go on to rough electrical and plumbing, mount the cabinets, [almost] finish the electrical (but not the plumbing), measure out the countertops, paint the area, install the countertops, install the sink, reinstall appliances (or install new ones), and finally finish electrical and plumbing, all with periodic cleanup at appropriate in-between periods — I found that everything made sense, and fell into place in much the same way that variables, subroutines, objects, and modules connect and build upon each other to form useful (and reusable) software.  Indeed, as he explained what was going on (and why), I found that he was using many of the same concepts that computer scientists use in designing, studying, and choosing among algorithms:

• Priorities: “We need to relocate the refrigerator first so that food storage is disrupted for the least amount of time.”


• Pre- and post-conditions: “I can’t start the cabinets until we’ve settled the rough electrical and plumbing, since the cabinets might get in the way.”  “The cabinets aren’t right until they’re completely plumb and level from end to end.”


• Fault tolerance: “It doesn’t make sense to order the countertops until the cabinets are completely laid out — that’s the only time that we’ll know the exact dimensions of the counter surface, since all kinds of adjustments and tweaks might happen during installation.”


• Scheduling/load balancing/optimization: “There’s no rush to pick out the sink or install the glass panes in the cabinet doors, since you can do that while everything else is going on with plenty of time to spare.”


• Efficiency: “If we cut the cabinet skin in this way, we’ll be able to use more of it to cover off these areas, with the fewest gaps.”


• Tradeoffs: “I can make that adjustment if you’d like, but it will delay this next step and cost a little more money.”


• Side effects: “While we can move the refrigerator, we can’t move the valve that feeds the ice maker. So we’ll need to shift these cabinets a little so that they can accommodate a connector between the fridge and the valve.“


• Constraints: “The countertop can only go this far through the kitchen pass-through, because the material won’t be strong enough to support itself past that.”

The list goes on — and every step of the way, I saw what was going on and why, and even though one might wish that things would go faster, or that some decisions were easier, I couldn’t help but appreciate how the big picture, and all of the factors involved, really compelled the work to proceed in a certain way.  The contractor might even have been slightly surprised at my demeanor, as he started telling me horror stories of how other jobs got derailed due to unreasonable demands or fickle decision-making.

In the end, it came down to one thing — we were thinking about the task and its components in very much the same way.  Thus, a good contractor would make a good computer scientist.  And, if a computer scientist somehow learned to deal with a nail gun, circular saw, and plumber’s dope, then that computer scientist might make a good contractor!  :)

Let’s take it a step further, in fact — for what endeavors or fields would considerations like those listed above (and numerous others from the computer science realm) not be useful at all?  Of course, I may be biased, but I think one can make a pretty strong case that almost every facet of the human experience would benefit from some kind of computational proficiency — and I mean “computational” in the general computer science sense, not just the numeric manipulation that most folks would associate with the term.  In the end, wasn’t the contractor really “computing” a new kitchen, based on the “input” provided by the homeowner?

A music professor once told me that a quality shared by all good music, regardless of genre, was that it was “logically compelling.”  He didn’t mean that good music was mechanical or overly structured; he meant that good music always seems like it must go to a particular place, and no other destination seems like it would do.  This is what makes pop songs “catchy,” and what gives arrangements an excellent “hook” — when you hear them, the sounds and silences that come before seem destined only to lead to the sounds and silences that come after; anything else would be wrong, or else just not-as-great.

The notion of “logically compelling” certainly resonates with me regarding good software design, both internal (the code’s structure) and external (the user interface).  On both counts, high-quality designs “compel” that code be written in a certain way or that a user’s intuition match what a user interface presents — all because factors such as priorities, pre- and post-conditions, fault tolerance, optimization, tradeoffs, constraints, and other core elements of computation are brought to bear upon a situation.

And now, after observing a kitchen remodel up close, I would say that a well-executed kitchen remodel is also “logically compelling.”  Indeed, if everybody knew a little computer science, how many more day-to-day human activities would share that property — a sensible result due to sensible decisions made based on sensible reasons, with sensible (and acceptable) compromises.  Would you trade some extra time and resources off for that mid-life adjustment?  Or better yet, start ’em young.  After all, I don’t know of anyone who doesn’t appreciate a brand-spanking-new kitchen.  :)

That Drowning Feeling

I once had a friend who fretted mightily about an upcoming party.  She had that deer-in-the-headlights look to her — simultaneously distracted yet fixated.  Upon some inquiry, I found out that the issue in question was the food: how much of it to order.  She bounced around about being worried that there wouldn’t be enough food, but such and such people haven’t RSVPed, plus these other people have a tendency to bring a bunch of other folk along, plus if there were too much, what would she do with it, does that mean she’ll need to get some boxes so people can take the excess home, but then she might order too little food…

This has happened to all of us at one time or other: we are faced with a situation that has a lot of unknowns, a variety of factors to consider (sometimes contradictory), and no apparent resolution.  Fortunately, we frequently don’t need to face these situations alone, and in this case, it was my turn to keep someone company.

Having (mostly) understood the problem at hand, I tried to get a few things straight.  First, I asked my friend how much food would be viewed as “enough” food for the guests.  She had a ready answer — for the kids at the party, she would want them to eat a certain amount; for the adults, a little bit more.  Memory of precise values and items escapes me, but the answer was definite and clear, something like “1 piece of pizza for the kids, and 2 pieces of pizza plus 3 buffalo wings for the adults.”

Little did my friend know that she had almost solved half of her problem for me.  I then asked how many people she expected.  A little bit of the fluster bluster came back, but, once focused on just a head count and not all of the implications of such a head count, she also had a fairly ready answer — “Well, I invited 30 people, but only 20 have RSVPed, and some guests might bring others along.”

Some uncertainties there, for sure, but before I pursued the head count further, I asked my friend, “What’s more important to you — that there’s too much food left over, or that there’s too little?”

Confusion city started looming again, but once more, I found my friend actually continuing to solve more of the problem on her own.  “Well,” she said, “I really want to have the right amount of food...but in the end, I wouldn’t know what to do with too many leftovers, and if the food looks like it’s getting low, I can always run out and get some easy ready-made stuff.  But if I can avoid that, that would be great.”

Which returned me to head count — I asked around how many “surprise” guests might show up, and she listed the invitees who have, in the past, brought in some freeloaders — uh, crashers — uh, no, um, extra mouths to feed.  For each invitee, she found that she had some idea of, at worst case, how many unsolicited additions might pop up.  In the end, we had a number — by no means a surefire one, of course, but still a guesstimate that sounded reasonable.

“Now,” I concluded, “with that fair guess of how many kids and adults might show, let's just multiply that by how much food you’d like them to eat, and that’s how much you should order.  If that amount goes over, then it probably won’t be way over; if it goes under, then either it won’t be too bad of a shortage, and like you said, if you were really in a bind, you can always get some more food.”

That seemed to settle things.  My friend calmed down, settled on a quantity of food, and finally started to actually look forward to this party which had been causing her so much grief.  There was a final, lingering doubt — “So you think that will really be enough?” — but she seemed to replay our backups and contingencies and priorities in her mind, and squashed that question once and for all.

Of course, at this point, you may be wondering, “Now where is the computer science in all of this?”  Looking back, I would say that the entire food-amount-determination episode comprised the computer science.  Assessing a situation, looking at its positives and negatives, specifying priorities, and finally coming up with a plan that maximized the positives while handling or accepting possible negatives, is, in some respects, precisely what computer scientists do for a living.  This cycle happens all the time, particularly with algorithms: there is almost always more than one way to approach a particular computation.  Each alternative has its own set of advantages and disadvantages; for many problems, there is no clear winner.  When deciding how to allocate files on a disk, one may favor the simplicity of contiguous allocation but realize that frequent changes to files on disk may eventually lead to external fragmentation.  Thus, other approaches that are more amenable to change (linked lists, indices) should be considered.

And yet, we must realize that the very notion of “frequent changes” is an assumption in this scenario — and sometimes, this assumption will not hold, such as with DVDs or other non-writable media.  In this case, perhaps contiguous allocation’s benefits then outweigh its detriments, precisely because our needs or priorities have changed.

In another area of computer science, computer graphics, lies the search for hidden surface removal algorithms.  A variety of approaches were devised and tested, each having different pluses and minuses when compared against each other.  The approach that proved to be the most general, with the best performance over a wide variety of situations, was the depth- or z-buffer algorithm.  It had one caveat, however: it used a lot of memory, possibly more memory than the visible graphics display itself.  Depth-buffer effectively “trades off” space in exchange for time — something that happens in many algorithms.

As you may have guessed, depth-buffer may have been prohibitive at first, but as memory became cheaper and more available in larger and larger amounts, depth-buffer’s “disadvantage” was finally rendered moot.  Today, kids bring around devices that use the depth-buffer.

Thus, like my friend and her food-at-a-party conundrum, computer scientists are frequently faced with unknowns and no clear-cut choices; unlike my friend, we are actually trained to tackle these situations in toto, so that we can determine not necessarily the absolute best solution, but the best solution under the current circumstances.  We are trained to be explicitly aware of these circumstances, as well, because one day, those circumstances may change, and all of a sudden another alternative may become preferable.

In the end, I’m left asking, if everyone knew a little more computer science, how many “deer-in-the-headlight” situations might actually be avoided?  How many people, mired in apparently insurmountable problems, might actually find a way through?  While there will certainly be challenges of genuine difficulty, one wonders how things might change if more of us could “swim” with the computer scientists, and thus not drown in every problem that isn’t blatantly cut and dried.