You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy .

Crossing Streams

Jamie
Jamie wrote this on 16 comments

When I switched to Android a few years ago, I promised myself this: I’d switch back the minute Apple added smart notifications, app data sharing, widgets, and a better keyboard to iOS.


Apple’s WWDC keynote yesterday was exciting. Craig Federighi is super awesome (I wanna hang out with him). iOS is finally getting the Android features I love. Yesterday I was ready to switch back, but now I’m not so sure.
Some iOS fans have pointed to Google’s Android as being a poor copy—thermonuclear theft. On the surface there are similarities, but conceptually Android started from a power user’s perspective. Where Android had power features it also lacked in the simplicity and obviousness of iOS. Simply because iOS did far less.
Yesterday Apple showed iOS doing a whole lot more. Apple is refining iOS by layering on functionality. They’re adding features to the simple iOS foundation. However, the more features there are, the more complicated it becomes—and the harder it is to use.

Meanwhile, Google has done something interesting with Android. It started out as a very power-user complex platform, but they’ve been refining it in a different way than Apple. Instead of adding features, they’ve pruned them. Historically Google hasn’t been afraid to nix apps or services in an effort to focus and simplify. You can see these efforts in Google Now. With Google Now you don’t interact with apps or widgets. Their “cloud” knows what you want to know and tells you. No interaction needed.


It’s always harder to take away features that are already there. But, I have no doubt Apple will try to continue making iOS easy-to-use while they layer on new power user features. At the same time, Google’s not afraid to take away features. Maybe Google will keep simplifying Android, pushing all you need to know from their sentient “cloud”.
I’m curious to see what happens next. But, I’m not switching back to iOS just yet.

One-hit wonder

David
David wrote this on 15 comments

It’s incredibly hard to trace the success of any business, product, or project down to the skill of the founders. There’s plenty of correlation, but not much causation.

That’s a scary thought to a lot of people: What if my success isn’t based solely on my talent and hard work, but rather my lucky timing or stumbling across an under-served market by happenstance? What if I’m just a one-hit wonder!?

And I say, so what? So what if you are? I, for one, am completely at peace with the idea that Basecamp might very well be the best product I’ll ever be involved with. Or that Ruby on Rails might be the peak of my contributions to technology.

What about my life would be any different if I could truly trace down the success to personal traits of wonder? Even if I somehow did have a “magic touch” — and I very much believe that I don’t — why would I want to leave those ventures, just to prove that I could do it again?

Yet that siren song calls many a founder, entrepreneur, and star employee. The need to prove they’re not a one-hit wonder. That they’re really that good because they could do it again and again.

For every Elon Musk, there are undoubtedly thousands of people who left their one great idea to try again and fell flat on their faces, unable to go back to the shine and the heyday of that original success, and worse off for it in pride, blood, and treasure.

Life is short. Move on if you don’t love what you’re doing. But don’t ever leave a great thing just because you want to prove to others or yourself that you’re not a one-hit wonder.

What Jamis left behind... for us.

Jason Fried
Jason Fried wrote this on 15 comments

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)

It's OK not to use tools

Jonas Downey
Jonas Downey wrote this on 54 comments

Recently I did a little side project to improve the website for a non-profit animal shelter in our town. The existing site was an outdated Microsoft FrontPage menagerie, so basically anything I did would be a big improvement.

I spent around 20 minutes creating a simple design in HTML, and then several hours editing, rewriting, and refining the copy. In the end, I reduced a scattershot 25-page website down to about 8 focused pages written in a friendly tone.

My next instinct was to apply our great modern web toolset to the site. Let’s add a static site generator or a CMS! Let’s add Sass and a grid system! Let’s do more fashionable things!

Then I started looking at those tools critically. A static site generator usually requires knowing Markdown and esoteric commands and configuration. A typical CMS will need setup, logins, security patches, templates, and maintenance. Even hosted CMSes have a lot of cognitive overhead, and the content is trapped away inside someone else’s system.

These are tools made by geeks, for geeks. Why do we need a CMS for an 8-page site? And for that matter, why even bother with Sass? Regular old CSS can do the job just fine.

Who knows who will take over the site in the future. I’ll hang with it for a while, but someday someone else might have to work on it. It would surely be easier to do that with 8 simple, straightforward HTML files than with some custom WordPress installation that’s several versions out of date. So what if I have to repeat the navigation markup 8 separate times? It’s not that hard. We used to do it for much larger sites!

Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?

As builders, we like tools and tech because they’re interesting and new, and we enjoy mastering them. But when you think about the people we’re building for, the reality is usually the opposite. They need simple designs, clear writing, less tech, and fewer abstractions. They want to get stray animals adopted, not fuss around with website stuff.

Remember when the web was damn simple? It still can be. It’s up to us to make it that way.

My brother made a video tribute to one of my favorite artists: Elwood T. Risk. Woody worked as a construction worker for many years before “giving himself permission” to become an artist. Now he’s had work featured all over the place, including the show Californication. Great guy, great story, great art.

jeepsubject.png

I really like Jeep’s text-based 7-bars + headlights subject lines in their marketing emails. Fun touch.

Jason Fried on May 14 2014 3 comments

Captured by quality

David
David wrote this on 7 comments

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.

The Great M&M Taste-Off

Dan Kim
Dan Kim wrote this on 23 comments

We spend a lot of time in Campfire chatting and debating—it’s our virtual water cooler. Recently one particular debate stuck out that had to get settled…

What’s the best tasting M&M on the market today?


Left to right: Our office frog presiding over the event, Peanut M&Ms, M&Ms, Dark Chocolate Peanut M&Ms, Peanut Butter M&Ms, Reese’s Pieces (for contrast, and because we love E.T.)


After careful consideration, an esteemed panel of six judges voted on their favorite. By the narrowest of margins, Peanut Butter M&Ms claimed the throne. The votes broke down as: (3) Peanut Butter M&Ms, (2) Peanut M&Ms, (1) Dark Chocolate M&Ms.

What do you think—are our judges crazy? What other M&M’s should have been included? How did the Peanut Butter M&M disrupt a decades-old market of traditional M&Ms? ;)


Next up: Twix v. KitKat

Drive development with budgets not estimates

David
David wrote this on 11 comments

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.

Responsive design works best as a nip'n'tuck

David
David wrote this on 15 comments

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.

Hybrid sweet spot: Native navigation, web content

David
David wrote this on 41 comments

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…