The sun beat down on poor Brett¹ as he surveyed the pieces around him. When he had taken the job to erect a pre-fab shed in a neighbor’s backyard, he had thought it wouldn’t take him more than an hour. Having just failed in his fifth attempt, he was about ready to pack it in.
“Hey, how’s it going?” Gary² called from his car window as he drove up.
Brett walked down to the sidewalk. “Not so good. I’ve tried at least three different ways of putting this shed up, and I just can’t figure it. I need like six extra pairs of hands just to hold the walls in place so I can add these braces to hold the whole thing together. ‘Easy assembly,’ says the instruction sheets, but I’d have to be The Flash to be able to do some of these steps before the weight pulled it down.”
“Hmmm, let me take a look.” Gary got out of the car and then quickly paged through the instructions. “Yeah, this looks a bit tricky. Care for a suggestion?”
“Are you kidding me? If I don’t figure this out soon, I’ll still be here come midnight. Heck, I’ll still be here come October.”
“Walk with me for a minute.” Brett turned to follow as Gary walked down to his house, just a few doors away.
“I think what you need here is an extra pair of hands, and I’d be glad to help you if I didn’t have some other errands this afternoon. But I think I can give you the next best thing,” Gary said, as he turned up his driveway towards a small detached garage.
Beside the garage was a stack of warped 1” and 2” by 4”s. “Now, you should take a few of those over and see if you can’t build yourself some supports; just enough to hold each wall steady while you do what you need to.”
Brett examined the stack of wood, leftovers from some repairs that had been done in the garage a few months previously. It was all junk wood, warped beyond usefulness and destined for kindling when winter came. But certainly it’d be strong enough to hold a wall or two in place, if he framed it right.
“Can I borrow a hammer and some nails, too?”
“Sure, you know where they are, just put back whatever you don’t use when you’re done.”
“See you around dinnertime?”
“I think *now* you will.”
One of the hallmarks of coding experience is knowing when to build something completely throwaway, in the service of the work you’re doing. Indeed, I’ve heard more junior engineers remark of how a senior programmer really knew how to approach problems by building the right tools to understand the problems they were facing. Due to a work experience from long before I was a professional coder, I like to think of the code we write to figure out the problems we face as scaffolding.
Scaffolding is the work you do to help you deliver the work you’ve agreed upon. I’ve employed, and seen employed, many forms of scaffolding over the years, but each and every time I see a bit it follows a few general rules:
- It’s cheap. Scaffolding shouldn’t take you long to do³ — it’s simple work that doesn’t respect the needs of shipping code, from memory consumption, performance, or any other work. You build it quickly and put it to use immediately. Often, it doesn’t even survive long enough to get checked in.
- It’s dirty. Really, this goes hand-in-hand with it being cheap, but if you find yourself thinking too much about your scaffolding, you’re probably working too hard on the scaffolding itself. If you’re trying to put up a shed and need a temporary wall to hold together a couple of pre-fab pieces, you don’t expect those pieces to look as good as the finished product you’re making. In fact, no one will likely ever see it, it may not even survive the project. So, feel free to write against all the rules you’ve been taught and whatever coding methodology to which you subscribe — go in and remove encapsulation from objects so you can access members directly, use terribly abusive algorithms, write reams of data to disk, access memory randomly, hold raw pointers that just happen to be safe… just don’t overthink it.
- It’s useful. There is one measure, and one measure only when it comes to good scaffolding: utility. Scaffolding code is built only to be useful to solve other problems, not to present problems which need to be solved in itself. Once you’ve written the bits you need and answered the questions you needed answered, it’s time to move on.
- It doesn’t ship. Take it out before you check-in (whether through pre-processor macros or brute force). Just be sure not to leave any traces which might slow down or bloat your end-product or leave extra rusty nails lying around where someone might step on them — in particular, replacing any guards that were in place, such as objects’ access protections and the like. You want to leave a clean workspace behind.
When approaching a problem that’s a little bit beyond your ability, or just unfamiliar enough to require serious thought, consider building a little scaffolding to help you through it. If you find yourself wondering what approach to take, ask yourself questions like “What information would I need to approach this problem in the right way?” and “What sort of code would help me address this problem more easily?” and build yourself a little scaffolding to give yourself good answers to those questions. It might seem like it takes you off-task for a while, but it’s often helpful enough to generate a much better solution in the long run.
Brett Douville is the lead systems programmer at Bethesda Game Studios, maker of Fallout 3 and the forthcoming TESV: Skyrim. He blogs occasionally at @brett_douville.
¹Names changed to protect the innocent.
²Oh, who am I kidding. Although I’m a second generation computer programmer, the best lessons my dad taught me about coding had nothing to do with programming at all.
³Though it might give you ideas for future work, given time to properly build for your engine. Today’s scaffolding might point you in the right direction for tools that are currently missing from your codebase.