A few weeks ago, Jamis Buck, a programmer who had been with us for nine years, asked to meet with me and David. We grabbed a conference room, and I immediately felt something heavy in the air. Jamis told us it was time for him to move on. He’d had an incredible run, but recently he’d felt stuck. He wasn’t sure yet what he would do next – which terrified him – but he had to follow his heart.

Naturally, it was hard to hear. We love Jamis. Everyone who’s ever met Jamis loves Jamis. The guy is a model of honesty, hard work, and humility. But we knew deep down it was time. As he poured his heart out to explain, we offered no resistance, only support.

Now that Jamis has moved on and time has pushed some emotions out of the way, I’ve been thinking about his legacy here at Basecamp. On the one hand, losing Jamis means we’ve lost a cultural touchstone. Maybe you’ve had a similar experience: A key team member takes with her a piece of the company’s soul. But the situation also presents an opportunity to make sure that the person’s values stay with the company, so I sat down and tried to identify the principles of Jamis’s success. I’m not sure yet how we’ll formalize some of these things, but just reflecting on his impact will, I’m sure, help carry it forward. So here it is, the Jamis Doctrine…

Respect the Work

Jamis wrote code that was concise, clear, and thoughtful. He coded the way a great writer writes prose, which is to say he did it lovingly and invested himself in the work. Because Jamis was the second person ever to touch the Basecamp code base, his example is all over the place, and every programmer gets to learn from it. I hope his example will resonate with people in other departments, too. It’s never enough just to get the work done.

Take Time to Teach

Jamis always did. Whether that meant helping another programmer or showing someone in customer service how something worked, he was always available and eager to explain. When people wrote up their goodbyes to Jamis, many of them mentioned things he’d taught them. What a great example to follow—it’s the kind of thing that turns co-workers into a team.

Stay Hungry

Jamis took on an interesting new hobby every year. One year, he learned to make bow ties (and made some for all of us). Another year, he mastered the art of marshmallow making, and another he learned to draw (and started hand-illustrating his presentations). This past year, he decided to write 1,000 words a day. Jamis’s deep curiosity – and willingness to share it – was one of the reasons we instituted a continuing-education benefit years ago. I hope we can continue to help everyone at Basecamp pursue personal interests, because an intellectually satisfied employee is a happy one.

Do the Right Thing, Not the Easy Thing

Jamis always put what was correct before what was convenient. In nine years, I can’t remember talking to him and not feeling as if he gave me a straight answer. There’s a difference between aiming to please and aiming to please properly, and he did the latter. In many ways, it was that quality that inspired me most, and it’s especially important for me, as the boss, to embrace it.

Spread Sweetness

A box arrived today at work. In it was a short story that starred two characters named Basil and Fabian. Over the years, Jamis had written a series of weird little tales that starred these two. This time, Basil and Fabian were talking about marshmallows. There was a personal note from Jamis in the box, and nestled below that was a bag of his chocolate-covered coconut marshmallows. I ate one – OK, two – and smiled. I think everyone at the office did.

(Note: this article was originally published on Inc.com)

Making stuff good is rewarding, making stuff great is intoxicating. It’s like there’s a direct line from perfection and excellence to the dopamine release. And the reverse is true as well. When you make crappy stuff, you feel crappy. No one likes to work in a broken shop on a broken stool.

So it’s hard to fault people from being attracted to sayings like “Quality is Free”. It validates the good feelings that flow from making stuff perfect, and it makes it seem like it’s a completely free bargain. Win-win and all that.

But like anything, it’s easy to take too far. Almost everything outside of life-critical software has diminishing returns when it comes to quality. Fixing every last bug, eradicating every last edge case, and dealing with every performance dragon means not spending that time on making new things.

You can make the best, most polished, least-defective saddle out there, but if the market has moved on from horses to cars for general transportation, it’s not going to save your business. And it doesn’t even have to be as dramatic as that. Making the best drum brakes is equally folly once disc brakes are on the market.

So you have to weigh the value of continuing to hone and perfect the existing with pursuing the new and the novel. This often happens in waves. You come up with a new idea, and a crappy first implementation. You then spend a couple of rounds polishing off the crap until the new idea is no longer new and crappy, but known and solid. Then it’s time to look hard at whether another round is worth it.

The bottom-line is to make that which is not good enough, good enough, and then skate to where the puck is going to be next.

Much of software development planning is done through estimates. You give me a description of the feature, I give you a best guess on how long it’s going to take. This model has been broken since the dawn of computer programming, yet we keep thinking it’s going to work. That’s one definition of insanity.

What I’ve found to be a more useful model is simply to state what something is worth. If a feature is worth 5 weeks of development, for example, that’s the budget. Such a budget might well be informed by an estimate of whether some version of that feature can be possibly built in 5 weeks, but it’s not driven by it.

Because most features have scales of implementation that are world’s apart. One version of the feature might take 2 weeks, another might take 6 months. It’s all in where you draw the line, how comprehensive you want to be, and what you’re going to do about all those inevitable edge cases.

The standard response to the estimation approach is to propose a 100% implementation that’s going to take 100% of the effort to build. Some times that’s what you need. Nothing less than having everything is going to be good enough. I find that’s a rare case.

A more common case is that you can get 80% of the feature for 20% of the effort. Which in turn means that you can get five 80% features, improvements, or fixes for the price of one 100% implementation. When you look at it like that, it’s often clear that you’d rather get more done, even if it isn’t as polished.

This is particularly true if you don’t have all the money and all the people in the world. When you’re trying to make progress on a constrained budget, you have to pinch your development pennies. If you splurge on gold-plating for every feature, there’s not going to be anything left over to actually ship the damn thing.

That’s what proposing a budget based on worth helps you with. It focuses the mind on what assumptions we can challenge or even ignore. If we only have 5 weeks to do something, it’s just not going to work to go through the swamp to get there. We have to find a well-paved road.

In the moment, though, it can be frustrating. If we just had a little more time, we could do so much better! So much better for whom? Your developer pride? Or the customer? Will the latter actually care about all the spit and grit you poured into these particular corners? Don’t be so sure.

In the end, accepting a budget is about accepting constraints. Here are the borders of scope for our wild dreams and crazy colors. Much of invention lies in the fight within those constraints. Embrace that.

It’s pretty amazing how far you can take responsive design these days. Between the latest CSS tricks and a splattering of JavaScript, you can turn an elephant into a mouse, and make it dance on a parallax-scrolling ball. It’s time to reconsider whether you should, though.

There’s a point on the trade-off curve where rearranging everything, hiding half the page, and then presenting it as “the same template, just styled differently” is simply not meaningful. Nor is it simple. Nor is it efficient. A one-size-fits-all HTML base document is not a trophy-worthy accomplishment in itself, lest we forget.

The way we think about this at Basecamp is as a nip’n’tuck. If you’re just stretching or shrinking things a bit, then responsive can definitely be easier (we do that on this blog, for example). But the further you move towards a full make-over, the less it makes sense.

This is particularly true if your framework of choice doesn’t make it needlessly complicated to use separate templates for separate purposes. Rails 4.1 has a feature called variants that makes it trivial to share the controller and model logic of your application, but return different HTML templates when the devices call for it. It’s this feature we’re using for the Basecamp mobile views (which in turn are embedded in our mobile apps) instead of the prevailing responsive paradigm.

By going with dedicated templates, we don’t have to include needless data or navigation that’s going to be hidden by the responsive rules. We have less variables to think about on the individual page. It’s just a simpler workflow where it’s easier to make changes without considering a smather of side effects.

So the next time you’re marveling at a responsive design that’s able to make the best use of a 27” iMac at full screen and a fit neatly on a 3.5” iPhone as well, you might want to ask yourself why you’re trying to make one performer do so many tricks.

When we launched the iPhone version of Basecamp in February of last year, it was after many rounds of experimentation on the architectural direction. The default route suggested by most when we got started back in early/mid-2012 was simple enough: Everything Be Native!

This was a sensible recommendation, given the experiences people had in years prior with anything else. Facebook famously folded their HTML5 implementation in favor of going all native to get the speed they craved with the launch of their new app in August of 2012.

Thus their decision was likely driven by what the state of the art in HTML and on mobile looked like circa 2010-2011. In early 2010, people were rocking either the iPhone 3GS or 3G. By modern 2014 standards, these phones are desperately slow. Hence, any architectural decisions based in the speed of those phones are horribly outdated.

Continued…

I’ve always had a fascination with old. Old trees, old buildings, old people, old objects, and old businesses.

The world is constantly pushing the old out of the way to make room for the new. So if something can stand up to the world, push back, and go the distance, then there’s probably something special about it. I believe those things are worth celebrating.

Today we launch THE DISTANCE, an online magazine that celebrates one type of old thing – the old business. THE DISTANCE is about interesting private businesses that have been in business for 25 years or more.

Everyone talks about how hard it is to start a business. It is hard, but it’s not as hard as staying in business. Every business is new at least once, but very few actually survive to old age (or even adolescence). We want to celebrate those who’ve figured out the hardest thing to do in business: how not to go out of business.

Some of the businesses we’ll be covering have been in business for a hundred years or more. Some are still run by the original founder. Some are now run by a long-time employee. Some are run by the son or daughter of their father’s grandfather who founded the business way back in the day.

Every month we’ll be publishing a new article about one of these businesses to thedistance.com. We’ll introduce you to some real characters, some amazing stories, a few secrets, and the sustained blood, sweat, tears, and persistence required to keep the lights on for so many years.

Our first article is about the Horween Leather Company out of Chicago Illinois. A fourth-generation business founded in 1905, Horween makes leather the old fashioned way. As the last remaining tannery in Chicago, they’ve stood strong, learned how to survive – and thrive – in a challenging environment. They have a lot to teach us.

If you like these kind of stories, we invite you to follow @distancemag on Twitter. We’ll be sharing all sorts of things about old businesses, long-time employees, and other tidbits you may find interesting. Whenever we publish a new story to THE DISTANCE, we’ll announce it first on the Twitter feed.

So, here we go! Head over to thedistance.com to read the story of Horween Leather, the last tannery in Chicago.

And BTW, if you know of great little 25+ year private businesses that would be a good fit for THE DISTANCE, we’d love to hear about them. Could be the mom and pop shop around the corner. Could be the holdout manufacturer on the edge of town. They’re all interesting to us! Drop an email to [email protected] and we’ll follow up. Thanks for helping us with THE DISTANCE.

“All that work, and that’s it?”

I remember thinking this to myself a few weeks ago. I’d been building a new homepage for Know Your Company. But I didn’t feel I’d made much progress.

I’d rewritten copy, collected stories from current customers, designed several new pages, made the site more mobile-friendly…

Yet despite these changes, the site didn’t look much different than before. I began to question if I’d accomplished much at all.

Luckily, as I started to feel this way, I happened to be chatting with Jonas, a designer at Basecamp. He’s also the original designer of Know Your Company, and has helped me transition the product into its own company.

Jonas said this to me:

“Claire, go read what the homepage had before.”

I went and did that.

“Okay. Go read it now with your changes.”

I went and looked at my new site.

“See? Before, people looking at your site didn’t know what customers thought about your product. Before, they couldn’t request a product demo as easily. Now, your revised design helps people do those things. So don’t get discouraged because your design doesn’t look different. If you read it, you’ll see it’s much better than it was before.”

What a great reminder.

I’d forgotten my progress simply because it didn’t look different. When you just look at the difference, you might not see much. Text looks like text, regardless of what it’s saying. But if you read the difference, you see how big your changes actually are.

Progress isn’t measured by how different something looks. It’s measured by how useful something has become. Is it making this person’s life easier? Is it doing the job you want it to do? Reading the difference, not just looking at it, reveals your progress.

So the next time you doubt how much progress you’ve made, don’t look at the difference. Read the difference.

You’ve probably accomplished more than you give yourself credit for.