These are my first-blush reflections on BaseCamp’s Shape Up methodology:

• The six weeks of focused burn/two weeks of cool down and clean up sounds delightful, but also seems like it works best with an established product to which a team is adding pretty meaty features. (Some of our entire implementation projects are 8 weeks front-to-back, so it would be hard to work this way there.)
• Using very low-fi models (“breadboarding”/”fat marker diagrams”) for initial exploration of the idea seems an excellent practice, both to minimize initial effort and to keep ideas high-level and abstract.
• I love the idea that the designer and developer are actively working together to create a feature within the pretty broad bounds that the author of that feature establishes. It does, however, require that the designer can actually create the necessary code/files for UI herself. This might be HTML/CSS/JS for web, Scenes for Unity, or Storyboards/SwiftUI code for iOS. Many designers I’ve worked with wouldn’t have been comfortable with this, but it seems like a really efficient way to work if you can get over that barrier.
• Scoping and hill charts seem like a great way to be able to talk about a feature and to communicate status and progress. I’ll probably steal the idea of hill charts immediately for progress discussions.
• Handling “shaping” asynchronously with a touchpoint at the betting table also sounds very sensible, though it requires a high level of trust that the folks who will be making bets proactively read and understand the pitches in advance. Thinking through and identifying potential pitfalls in advance is also a useful practice.
• The idea of not maintaining a backlog is a fascinating one. Since the backlog can become the dumping ground for every idea that anyone has ever had, this seems both liberating and scary, as it seems to open the door for something important to slip by. But as they point out, if it’s really important, it’s probably on someone’s mind enough to champion.
• This process is different enough from other methodologies and infrequently enough used that it will probably work best with a persistent team, rather than rotating contractors.
• In short, this seems like a process I would love to work with, but which is best suited to long-running, ongoing products, which most of my work currently is not.

Early on in my career, I worked at Motorola doing desktop support for the 800 people in their Paging Products Group in Fort Worth, Texas. Our team was responsible for the care and feeding of hundreds of Macintoshes, including keeping their anti-virus software up to date. This normally happened automatically over the network, but for one particular update, we were going to need to push an installation package out to all of the machines individually. That job fell to me and my friend Rich.

“Ugh,” I said to Rich. “We’re going to have to pull up our central management console, go down our entire list of machines, and one by one, send them this update. That’s going to take hours of seriously tedious work.”

“No way!” Rich responded. “We don’t have to do all of that boring work ourselves; we can automate it with a macro engine!”

“But Rich, it’ll take longer to build that script that it would take just to do this manually. And we’re on a deadline here.”

o “How about this?” he rejoined. “We split the job up. You do half of the updates manually. I’ll write the automation. And we’ll see who gets done first.”

This sounded fun (and meant I would only have to do half of the updates myself), so I quickly agreed to his scheme.

The next few hours saw a titanic struggle. I busily banged through the long list of machines, triggering the updates, waiting for them to complete, going on to the next, and thinking about how to minimize my keystrokes and do things most efficiently. (After all, my geek cred was on the line.) At the same time, Rich was building and refining his script, going down blind alleys once in a while but generally making solid progress while steadily throwing good-natured barbs my way.

As I approached the end of my list, I looked over to see that Rich finally seemed to have his script in good working order. He kicked it off, and it began chewing through his list at an impressive rate. I redoubled my efforts, doing my best to beat the machine, feeling like the modern equivalent of John Henry, the steel-driving man. (Though I was more a steel-rimmed glasses-driving man.)

At the end of that struggle, we finished up our respective lists within minutes of each other. Rich and I laughingly conceded that it was, for all practical purposes, a tie.

But…

In my heart of hearts, I knew that Rich had really won. Why? For a few reasons:

• Rich’s solution scaled better. Once he had his script built, he could have tackled my list too with little additional effort or time.
• The next time we needed to do a similar update, Rich’s work would allow us to accomplish it much more easily.
• Rich had done more interesting work. There’s nothing fun about doing the same series of a few keystrokes 800 times consecutively. But building a tool to do the same task is comparatively fascinating brainwork.

I kind of proved my point, but Rich equally proved his, and had way more fun doing so.

Traditionally, Sloth is considered one of the deadly sins. There’s much to this; if we are unwilling to work hard at things, we are considerably less likely to get far in life. But there’s a flip side to this, which is that working hard at the wrong things is even more ineffective.

All the vigor you pour into straightening up your desk doesn’t count for much when you’re supposed to be getting your homework done. If you need a hole for a swimming pool dug in your yard, you might be impressed with the industry of the guy who shows up in your yard with nothing but a stout garden trowel. But you won’t hire him for the job, because he’s not working on the right thing. I have a friend whose personal mantra is “Work smarter, not harder.” Sage advice.

When Rich and I had our contest, I was working on a first-order problem: how to update all of these machines. Rich was working on a second-order problem: how to automate a process to update all of those machines. In general, the further up you can go on that sort of hierarchy of abstraction, the more interesting the problems become, and the more effective the solutions are. I worked harder, but Rich worked smarter.

I’m not much of a woodworker, but one of the things I’ve picked up from my friends who are good at it is the importance of making jigs. Jigs are job-specific tools a woodworker creates to make the task at hand easier. If you need to make a series of identical cuts to 100 boards, you can do all of those individually. Or you can first build a little jig that will guide your saw to the right place, making those cuts easier, faster, and more consistent. Good woodworkers will create a variety of jigs as they create a piece of furniture. And as I’ve gotten better as a developer, I’ve found myself writing more and more tools to automate tedious or error-prone parts of my work, creating code that writes other code, rather than writing everything directly.

This is, I’m convinced, the reason that some developers won’t stop using the highly-customizable text editor emacs until you pry it from their cold, dead fingers. Once they have invested sufficiently in automating and customizing the task of editing text or source code, going back to doing it without all of their purpose-built tools becomes slow, inefficient, and error-prone.

Archimedes asserts that with a fulcrum and a large enough lever, he could move the world. So as a developer, you have a choice when you have giant rocks to move: you can push really hard on that rock, pushing on evenings and weekends to get it where it needs to be on schedule. Or you can learn to make levers. (And, because this is software, levers that push other levers.) You can build at a low level of abstraction, or you can learn how to build tools, how to build tests, how to do meta-programming, and when you do something more than twice, stepping back to figure out if you can automate that task.

Let’s stop pushing on rocks, and start building levers. This is how we can use our natural tendencies to be lazy to actually get more accomplished that we would by simply throwing ourselves into a task. And as a bonus, it’s not only more productive but a lot more fun too.