I used to love assembling my own computers. I say “used to” because somewhere between my first and the 200th, the love has grown cold. It took a long time, but the novelty eventually wore out. Now, I’m definitely a “have it show up in a box and just plug it in” kinda guy. Also, the difference between a fun hobby and the “grind it out” nature of doing it for work was partly to blame. We were über-thrifty at Discovery Mining and I had an insatiable thirst for computer hardware at the time, so we built our first few computer clusters by hand. However, it wasn’t long before we had outsourced this function: we simply couldn’t have scaled fast enough if we had continued to build our own computers. They never said it out loud, but I also think my team was grateful for the change: for our first couple of builds, even the CFO was installing CPUs and RAM in our make-shift assembly line!
For the sake of this article, I will mentally revisit those bygone days of hardware bliss and try to convey the geek-tastic pleasure I would get from poring over lists of parts. I loved researching and choosing the components: the motherboard, the RAM, the hard drive, etc. In general, I’m really into performance statistics, whether it’s frames per second, horsepower, watts per channel, or sprinkles per square inch (donuts). After my orgy of product research was over, I’d finally order the parts and then anxiously….wait…for them to arrive. Since this was a “race to the bottom” where price was concerned, I used the sketchiest of Internet vendors, the kind of places that were probably selling your credit card number to the Mafia. Therefore, at least one component would take weeks to arrive and hold up the assembly. When all the parts would finally show up, I was itching to build the system.
When that last part arrived, I’d quickly assemble the computer—for all the waiting that preceded, it never took long. Then came the most exciting part: booting up the system for the first time. However, I can’t tell you how many times my expectations were deflated like a pricked balloon when I pressed the power button and…nothing happened. This occurred a lot, until I became one with the Universe and discovered a troubleshooting strategy I call “Bare Bones” (I’ve also heard it called “back to basics”). The idea is simple and effective: you can often remove or disable unnecessary components in order to get a machine to work.
Let’s say you have assembled the following components for your sweet new gaming rig:
- Power supply
- Video card
- Sound card
- RAID card (controls the hard drives)
- Hard drives
- Network card
- DVD drive
You put it all together and press the power button. It doesn’t work, and you experience the sinking feeling of “did I just waste all this money assembling a large pile of useless computer parts?”
Don’t fret: just remember that not ALL of these things are required for the computer to work in its most primitive state. In fact, less than half of these components are needed to get the computer to boot. We can easily cut the above list down by over half to a list of the truly required components:
- Power supply
- Video card
Usually, when I would unplug or remove all the extraneous components, leaving just the essentials, IT WOULD BOOT!
Even more subtly, you usually don’t need all of a particular type of required component. For instance, you might have bought 4 sticks of RAM, but the computer will boot with one. Remember, for the “bare bones” strategy, you want the absolute minimum configuration which will work. If that means installing just one hard drive (as opposed to the 4 you eventually want to eventually use), just use one.
Now that you’ve got it to boot, you can go ahead and start adding in the rest of the components, one-by-one, to see which of them (and, there may be more than one) are causing the malfunction.
Bare Bones Everywhere
Bare Bones is a universal principle that applies to any machine that has subsystems or extra components that aren’t needed for basic operation. In our advanced technological world, there’s so many examples of things that have amazing “bells and whistles” that, while nice to have, simply aren’t needed for basic operation. In the context of the automotive industry, the number of features that car companies deliver gets longer with each new model year. Think about a modern car with GPS navigation, power windows, heated seats, a 10-speaker surround sound system, etc. The list of truly Bare Bones equipment (steering wheel, engine, accelerator, brake, 4 wheels, etc. – see photo above) has come to represent a smaller and smaller percentage of the components in your average car. Yet the strategy of reverting to these basic functions remains available to you, should you need to turn to them for troubleshooting purposes.
Of course, “basic operation” depends on how you’re using the system. Let’s say you have a refrigerator truck that is inoperable and you can get it to run by going Bare Bones and disabling the refrigeration unit. If you’re hauling meat around, clearly the refrigeration unit is a “must have” and therefore the truck won’t be eligible for use in that capacity. That’s okay, because Bare Bones can be used as a triage technique: if the truck is broken down in the middle of rush-hour traffic, clearly your main goal is simply driving it to the repair shop. In that case, disabling the refrigeration unit in return for “basic operation” would be a big win!
Bare Bones In Aviation
As a pilot, I’ve encountered the principle of Bare Bones in aviation, codified in manufacturer manuals and FAA regulations. As strange and dangerous as it may sound, not everything on an airplane is required to work before you go flying! (Although, keep in mind that “minimum requirements” and “good idea” are not necessarily the same thing.) Studying to take the pilot exam, I learned the mnemonic “TOMATO FLAMES” to remember what must be minimally working in order to legally fly in clear conditions (VFR) during the daytime:
Oil pressure gauge
Manifold pressure gauge
Temperature gauge (liquid-cooled engines)
Oil temperature gauge (air cooled engines)
Landing gear position indicator
ELT (emergency locator transmitter)
Mistakes in aviation are costly, so the list of what can be broken is also strictly proscribed in the confusingly named “Minimum Equipment List” (MEL), specific to each aircraft. Here’s an example from the Cessna 182’s similarly-used “Kinds of Operations Equipment List,” which describes what must be working if you want to fly in various conditions:
In this excerpt, you can see that the main airspeed indicator is always required (noted by a “1” in each of the columns to the left of the entry: “G1000 Airspeed Indicator”), but the standby airspeed indicator only needs to be working if you intend to fly through clouds or in low visibility situations (IFR).
While the “TOMATO FLAMES” and MEL lists aren’t designed to be used for troubleshooting while flying (they’re supposed to be consulted before taking off), I’ve read accounts of pilots going Bare Bones in emergencies by shutting off unnecessary systems to conserve precious battery life or quell fires (e.g., turning off a flaming engine on a multi-engine aircraft). Whether on the ground or in the sky, the principle is the same: not every subsystem is required for a machine to function. Conversely, the corollary is also true: a malfunctioning subsystem may be preventing a machine from functioning (and you may need to shut it down or remove it to restore system operation as a whole).
Bare Bones In The Digital Domain
I find that the Bare Bones strategy has its fullest expression in the digital world. That’s because stripping an electronic device down to its bare essentials is usually just a matter of a few keystrokes. You can go from a very complicated configuration like this:
pager lines 24 mtu inside 1500 mtu outside 1500 no failover no asdm history enable arp timeout 14400 nat (inside) 0 access-list inside_nat0_outbound access-group 101 in interface outside
to Bare Bones by simply adding something to the front of every line (sample commands taken from a Cisco network router configuration). In the parlance of programmers, this is called “commenting out” a line, an act that renders the command inoperable:
!--- pager lines 24 !--- mtu inside 1500 !--- mtu outside 1500 !--- no failover !--- no asdm history enable !--- arp timeout 14400 !--- nat (inside) 0 access-list inside_nat0_outbound !--- access-group 101 in interface outside
Removing items from a digital device’s configuration is typically very easy. Whether it’s putting a “!” “#” or “/*” at the beginning of every line, or a clicking a checkbox on a web-based form, the principle is the same. Being able to turn on and off functionality with just a few keystrokes is a huge advantage over mechanical systems, where disabling functionality usually requires a lot more work (and the turning of wrenches and screwdrivers).
A very fruitful strategy is to bring a device back to its simplest state and then add back in your configuration options one by one:
pager lines 24 !--- mtu inside 1500 !--- mtu outside 1500 !--- no failover !--- no asdm history enable !--- arp timeout 14400 !--- nat (inside) 0 access-list inside_nat0_outbound !--- access-group 101 in interface outside
until the offending option that is preventing the machine from working has been identified.
I think the importance of Bare Bones as a troubleshooting technique will only continue to grow. The prevalence of “feature bloat” in mass-produced products seems to only increase as time marches on. Tight QA budgets don’t often allow for every feature permutation to be covered in a product’s testing phase. Remembering that a machine has both critical and extraneous equipment allows you to bypass crippling interplay between the two by stripping a machine down to its bare essentials.
*** Questions? Comments? Have a related troubleshooting story that you’d like to share? Feel free to leave your feedback in the comments section below! ***