Yak Shaving: Hacker Mode Vs Maker Mode

When I start up a new project, one that’s going to be worth writing up later on, I find it’s useful to get myself into the right mindset. I’m not a big planner like some people are — sometimes I like to let the project find its own way. But there’s also the real risk of getting lost in the details unless I rein myself in a little bit. I’m not alone in this tendency, of course. In the geek world, this is known as “yak shaving“.

The phrase comes obliquely from a Ren and Stimpy episode, and refers to common phenomenon where to get one thing done you have to first solve another problem. The second problem, of course, involves solving a third, and so on. So through this (potentially long) chain of dependencies, what looks like shaving a yak is obliquely working on cracking some actually relevant problem.

One thing that helps me to navigate these treacherous waters is to classify a project into one of a couple modalities before starting: is it a Hacker-mode project, or a Maker-mode project, or somewhere in between? Hacker and Maker projects require different tools, different degrees of certainty in planning the outcome, different working methods, and different approaches to yak shaving. Sorting this all out beforehand is at least worth the few minutes it takes to think it all through.

Maker Mode

Some projects are started purely to get the project done. That sounds simple enough, and of course there are many steps along the way from idea to finished work, but the prototypical Maker-mode project can be planned out in detail from the start, accomplished with “normal” tools using skills that you’ve already got, and not a place for yak shaving. For these projects, the biggest obstacle to success is just doing it.

This is where tools like pre-canned software libraries and off-the-shelf parts or modules are great. The point of a Maker project is to get the thing made, and there’s no sense in reinventing (or even refining) the wheel. Maker mode projects are great to ship out to PCB houses as well. Plans can be made, parts ordered, and the relatively slow turnaround in external board fabrication just adds a delay rather than lengthening the amount of time it takes to get the project done. You might as well get started on the next project while waiting for delivery, because the board will “just work”.

The extreme Maker stance on yak shaving is that it’s always a waste of time. Spending too much time on tiny or inconsequential parts of the project risks delaying the whole. When you nonetheless find yourself down a yak-shaving dead-end, it’s a good time to think if that part of the project is essential, or if it can be approximated, allowing one to move on. Make everything as smooth as possible. Get it finished.

(Contrary to the “Cult of Done” folks’ assertions) Maker mode is not an excuse to be sloppy or avoid detail work. Indeed, because issues can be foreseen, it makes sense to plan things out and avoid uncertainty and mistakes upfront. In building an SD-card-based audio recorder, for instance, you know the frequency response you need, can figure out the data rates, and can select the right hardware and firmware from these data. Wire them up in the easiest way possible, and get it done.

Hacker Mode

Hacker-mode projects are a lot fuzzier from the start. A hacker mode project often starts out with a new piece of gear, and a vague idea that it can be made to do something interesting. Maybe the SD-card audio recorder example above is actually a bat-call recorder, and the microphone is only spec’ed up to 20 kHz but it could probably be run a lot higher. Or maybe the project is looking into an IoT device to see what makes it tick, and if the firmware can be broken into. Only one way to find out!

The planning phase is often more about assembling a list of possibilities than making a list of sequential steps; hacking is dealing with uncertainties. Where planning a Maker-mode project answers “how do I make this?”, planning a hacker-mode project runs more along the lines of “I wonder if I can make it do this?”.

[Sprite_TM]’s hard drive hack from OHM2013The tools needed for a Hacker project are lower-level. A scope, a logic analyser, and other gear that can be programmed to inject signals into the system under study are all handy. In Hacker mode, it’s good to have a well-stuffed toolbox, because you don’t know what you’re going to need, and what you’re not. Still, you don’t always have all the tools on hand that you’re going to need, and some of them will need to be custom-built. In the context of a Maker project, tool-building exercises are often undesirable yak shaving. In a Hacker project, the right (low-level) tool or insight can often be the key to success.

Hacker mode projects are also a lot less conducive to waiting time between steps. If you know that you’re going to have to repeat a step over and over again, it makes sense to spend some time optimizing that step. If it’s re-running a test a million times, you’re going to be happier if it’s scripted than if it involves pull-down menus. If it’s a PCB design that’s going to need to be respun five times over, a two-week waiting time to order the cheapest fabrication is repeated five times — it’s worth doing it yourself or paying for a faster service. Knowing where a Hacker-mode project is uncertain helps to manage the uncertainty.

The Real World

Do they need shaving?

Any real project is going to share aspects of these two extremes, of course. Some “purely” Maker projects will involve jig-making and tool-building to get the job done efficiently or beautifully. Those are yaks that need to be shaved. Conversely, unless you need very specific timings for some esoteric timing attack, there’s very little to be gained by writing your own bit-banged JTAG library; almost any Hacker-mode project can get by using an off-the-shelf tool.

The Hacker/Maker distinction is further blurred when you’re building a concrete project, but your actual goal is learning a new programming language or SDK or chip family. Learning projects are basically Maker projects, but the goal is picking up some new skills rather than a physical artifact. In learning projects, there’s little uncertainty — you can probably learn anything — but diving deep into the tools may be part of the goal rather than a step along the way. When your goal is to deepen your knowledge, what would seem to be negative yak shaving is actually the work you need to do. Indeed, once you’ve learned what you came to learn, it might be time to abandon the physical thing even if it’s not done, which is anathema to a Maker project.

The point here is to be explicit about the goal upfront, because it should influence the amount of planning, choice of tools, and even what constitutes positive or negative yak shaving along the way. If you find yourself caught up in infinite regress on an Maker project, write it up as a Hacker project to figure out later, and sidestep the issue for now if possible. Conversely, don’t feel that you should never be allowed to fully investigate some arcane aspect of a problem, because that’s where good Hacker insights come from. Some yaks just need shaving!

Oh just remembered another automotive related yak shave a few years before that. Vehicle needs front end rebuilding, so I’m in the middle of that, but front end parts absolutely caked in years of grit and grime, to even find some of the fasteners I need to clean everything off, no problemo, that’s what the pressure washer is for, grab it, hook it up to outside faucet and power, turn on, pleh-pleh-pleh-pleh, it’s farting and burping, hardly any water coming out, glance over to external faucet, there’s water running on the ground, go over there, it’s coming out alongside the freaking faucet… damn, go inside to look at the back and my basement floor is getting wet.. balls…unhook PW and turn off faucet… leak stops… damn must be split inside the wall, it’s a frost proof but some bugger must have left a hose on it sometime when it froze overnight. So doing plumbing now.. and no other vehicle here to go to home depot, apart from bike, get bike out, chain rusted, spend half hour freeing chain, lubing it up, pumping up tires.. go to home depot, get new frost proof faucet, plumbers solder, fresh can of propane for torch, all set… pedal home.. okay… follow the pipe back, there’s a shutoff on that spur, so turn it off, turn it OFF, grrrr, SNAP, shutoff bust… ohhhkayyyy, now I could ignore that and use main shutoff, but fuggit, I don’t want to have to do that another time…. so pedal back and get a shutoff… and here I managed to save 15 mins by taking the top of it off and transplanting parts from new one, no need to solder…great…. now got line drained, pull old faucet out, insert new one, solder up… go outside to finish the job and the mounting holes are further apart than old one, no worries, borrow hammer drill…. borrowed hammer drill… plug into external socket, no work, plug PW back in work, plug drill in no work. WTF??? oh wait, there’s some fault light flashing (Hard to see in sun, GFCI socket) so use tester on it.. yeah, somehow external power socket has funky fail, and refuses to work for 2 wire appliances, the PW has a ground on it… think about leaving faucet unfastened for now, but wobble it and hear it grind and figure I’ll get a fatigue fracture or it will wear through before I “get around to it.” damn, gotta do this properly, also may need this to work for other power tools before I’m done, sigh, ride back to home depot and buy a new GFCI socket, … fit GFCI socket, test, works, use drill, fasten faucet securely, back fill with expanding foam, job well done, pat self on back, hook PW back up clean the DUCK out of the wheel well and front end components, yay, can find control arm bolts now. But the light outside is going, it’s 8pm so pack up… go in go to washroom, turn on bathroom faucet to wash hands, it coughs and spits out chunks of crumbly washer… NOOOOooooooo!!!!!!!….. Though turned out, just this once, I had a spare washer, and just this once, nothing else happened while I fixed the washer, so next day I was able to get back to front end work.

” Conversely, unless you need very specific timings for some esoteric timing attack, there’s very little to be gained by writing your own bit-banged JTAG library; almost any Hacker-mode project can get by using an off-the-shelf tool.”

If you are a high level guy this makes sense and your stuff will either work and you may succeed or wont and you’ll move on to something else. If you are a low level guy you probably spend a lot of your time tweaking code that is too inefficient, because it’s too generic, or breaks because it’s not flexible enough.

When most hacker projects want ‘JTAG’ what they almost always want is something that isn’t part of the JTAG standards – it just connects using the interface. It turns out engineers can be quite creative when they are attaching their work with a hot glue gun. OpenOCD last I checked some years ago was merrily dancing down the road of replacing it’s old low level functions with ones that left the JTAG state machine in a defined state, and key to that was passing the register lengths with the instructions to be written. Which is fine when you know them, but you can be dealing with a chip with no IDCODE (Optional, thanks Joint Test Action Group) implementing a weird EJTAG varient (Thanks MIPS, Broadcom) on a 64bit CPU with an even weirder number of address bits and an apprently broken FASTLOAD mechanism. I think it might have been 36 address bits FWIW. Or because engineers like to have a laugh you can enter the TAP instruction, move to ShiftDR and have an *undefined* register length, for example because instead of a register, it’s a communications channel emulating a legacy debug method (STMicroelectronics, I’m looking at you!).

Most people would not be best served shaving yaks I agree, and most yaks would not be best served having people try, but if you have to do a waterfall plat on a bovid the highest mountain often has the best view.

Rarely, since I often get so caught up in the tools and possible features that my personal projects/ideas fail fail to get off the ground before a new idea comes along. When going from a working prototype to something I want to sell or really show off, that yak might need a shave.

I say that the bottom line here is “know thyself”. What aspect of a project do you get the most out of? The finished product or the process? The maker aims for the final product, the hacker the journey. Of course there is a spectrum and everyone is a bit of both. In my case, the journey is 80-90 percent of it — otherwise just buy it off the shelf. Setting up a website was interesting — the first time some 20 years or so ago, now it is just horrible grunt work. If there isn’t some challenge or sense of “can I pull this off”, it is hard for me to get motivated. So I always ensure there is some Yak shaving involved in every project. Does it look boring? Use a different programming language that I have been itching to use. Try python! That was OK the first time, then I ran screaming from the whitespace is syntax brain-damage. But you learn from real world experience. Like someone said, you should try certain foods so you can bad-mouth them with authority. But I am drifting off topic.

In a “production environment” the game would be entirely different, or at least biased much more strongly away from Yak shaving. It is hard to believe that bored silly engineers working under strict deadlines could do quality work, but maybe that is the test of the “true professional”. A clever engineer always finds a way to use a new and exciting microcontroller, or something to keep the interest level up. But even I like to cross the finish line with a project now and then.

I have many unfinished projects in both domains. My problem is I don’t catch my half shaved yak..I get a new yak and half shave it..then I get stuck with firmware issues and hence another yak. It has really taken a toll on my grammar.

Decide what you want to spend it on, there is a make / buy decision to be made at every level of a design.

If you don’t set goals then you are never done.

If you are brand new to the field then focus on ONE part of a design and buy the rest. Next project, focus on a DIFFERENT part, and so on until you’re able to complete projects and in each you have developed insight into specific parts of the design.

After a while you will have develop enough specialization to identify which parts of a project are worth your focus and which parts are better left to off-the-shelf.

If you have to spin a PCB 5 times and each spin takes 2 weeks (not counting lab time debugging things), you might want to rethink how you are doing things. It might work in software world wj\hen a compile takes minutes, but is not scalable for complex hardware project with lead time for parts, PCB and assembly.

Take the time and get everything design properly. Even if you take 4 weeks for the design process and two spins to get it perfect, you’ll come out ahead in time and save money too.

That is exactly the right course of action for a maker-mode project: plan, build, done! This type of comment, followed by the hacker-type comebacks, is exactly what prompted me to think about both of these sides in myself.

When there’s significant uncertainty in a project (“hacker-mode” in this article), planning horizons are significantly limited, and there’s no such thing as “design everything properly”. When experimenting, you just have to experiment. And 90% of the time, you run up on dead ends. In this particular context, imposing long delays to discover that a route is a dead end is very frustrating.

And that was kinda the point of the article. Some projects are plan-wait-build-done, and others are test-poke-fail-repeat-succeed. They require different working methods, and thus it’s good to characterize the project (at least informally) beforehand. (Man, I should respond to your comments before writing the articles! That’s a clearer thesis statement than you’ll find anywhere in the original.)

I don’t understand the first link – where is the link between Yak Shaving and Android Backups? The linked article doesn’t mention this expression and it seems a quite useful thing (if you own a Android phone).

Aside from that – seems to me the Cult of Done is really getting in the way of well… getting it done. I mean if all you;re interested in is getting is done, why bother with craftsmanship, or any pride in your work at all? Just check the Done box. In fact, why not just skip right to the end – you’re going to die one day, so why not just Get It Done?

To me the disciples of the Cult of Done ought to take note of the observation of Fred Brooks in his excellent book on software project management The Mythical Man Month, on page 21: “Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when is has not set in two minutes, the customer has two choices – wait or eat it raw. Software customers have had the same choices.”

I could never see where Ockham’s razor fits yet why the yak needs anything but being left with it’s range. Just two more examples where man can’t fit into nature, but tries to make it the other way around.