We’re hiring another iOS developer to help us build great native apps for Basecamp on all Apple platforms. You’ll join an existing iOS team at Basecamp that’s currently hard at work building a next-generation native app, but you’ll also help keep our legacy catalogue of apps humming.

It’s an offering for an experienced developer. You should have multiple shipped iOS apps under your belt (or one amazing one). You should be well-versed in iOS frameworks and APIs, but also be comfortable going off the golden path when necessary.

Our native development approach at Basecamp is hybrid. We combine great native navigation around WebViews and ground-up native features to get the best of both worlds: Productivity through shared codebases on the web, and great fidelity through native.

So while the bulk of the work is in ObjC/Swift, you should also be reasonably comfortable with both JavaScript and Ruby. Enhancing a Rails application to extend the API or tinkering with Turbolinks to make it work with a native-JavaScript bridge shouldn’t scare you.

It’s a great time to join Basecamp and our iOS team. We’ve recently gone all-in on Basecamp. Millions of people have used Basecamp, and our iOS apps are both well-liked and growing rapidly as the way people use the system. The latest work we’ve been doing, and that you’ll help us finish, will make that even more so the case.

We’re looking for someone who’s ready to do the best work of their career – without risking their health, sanity, or life outside of work. Basecamp is here for the long term. We’ve been in business for 16 years (5 before Basecamp, 11 since Basecamp), and we’ve been profitable the whole time. We’re not beholden to or on any venture capitalist timeline. Private and profitable allows us to set our own course given what’s best for our customers and employees.

We believe in taking great care of our incredible team, most of whom have been with us for a long time. This means lovely benefits to help you be the best you possible: fitness and massage allowances, fresh fruit/vegetable subsidies, helping out with continued education, matching charity donations, and of course great healthcare and retirement assistance (401k match in US). When you’ve been here for a year, you’re also in on Fridays off in the Summer. It’s a great package that’s part of creating a great scene.

Since we literally wrote the book on working remotely, we’re of course also open to applicants from both the Americas and Europe (any further away is tough to get enough timezone overlap). We do, however, expect your proficiency with English to be at or close to a native speaker. If you happen to be in Chicago, we have a great office for you to work from as you please. If not, we’ll pay for co-working space or help you outfit a great home office.

Does this sound like you?

Then please write [email protected] with [iOS Developer] as part of the subject line. We strongly encourage you to kill on the cover letter, but also to include links to some actual code you’ve written. If the code is on Github, you can share a private repo with dhh. (If it’s not possible to share code, that’s not a deal killer either, if you can blow us away otherwise).

Remember, it doesn’t matter where you went to school (or if you even graduated). We don’t care about how many years of irrelevance you have under your belt. The work is what matters as well as your willingness to improve yourself and everything you touch. We look forward to hearing from you!

(This opening has been cross-posted to WeWorkRemotely.com as well).

In the early days of Rails, a common dismissal of the framework and its Ruby roots were that these were just toys. Something for kids or amateurs to play with; to build a quick throw-away prototype or system of no consequence. It was most certainly not a tool for professionals building real systems for enterprise, king, or country.

Explicit in this charge against Rails and Ruby laid a grander, sweeping dismissal of toys of all kinds. And more specifically, a rejection of fun and enjoyment as valid reasons for adoption of technology that remains prevalent to this day.

The implication that real professionals do not bother with such childish indulgences. Making Serious Business Software is meant to be a chore. Something to be endured, not relished. An activity worthy of a stiff upper lip, not a smirk.

This charge against childish affection for unserious toys is often expanded to all sorts of wonder, and in particularly magic. In some circles, magic is now downright a dirty word. A label to be applied to anything appealing to greater aspirations than the khaki slacks efficiency of all that oh-so-serious Real Business Software.

But take a step back. Why on earth would we want to associate such joyful memories of learning about the world and its mysteries through toys and magic with that which is beneath us? Even though our goal may well be Serious, why must our approach? Since when is fun, novelty, and exploring the unknown at odds with productivity or value?

A phrase that’s been bothering me for a long time ties all this together: “Use the best tool for the job”. It implies that there is an objective, “best” tool for any programming job. And it leads the search towards those beige horizons of key-point comparisons and feature charts. This does X, Y, Z, thus it must be better than that which only does X and Y. It allows no room for simply preferring A to B on the account that it’s more fun!

Today Ruby and Rails are rarely accused outright of being toys. After more than a decade with roaring, overwhelming success creating an endless stream of “Yup, That’s Serious” business applications, the charge is now obviously preposterous.

But the same charges are still constantly brought against many things new, and as a favorite euphemism for toy goes, “unproven”. If there’s any sense of wonder or unexplained advantage, it readily gets that scornful label of “magic”.

It’s the lingua franca of the incumbents. The manifestations of a rigid minds trying so hard to appear above that childish sense of wonder.

The bottomline: Waging war on toys, magic, and wonder is simply a poor frame of reference. Many of us got into programming exactly because it seemed like magic, like playing with toys. Constructing intricate worlds out of nothing. Legos of logic and rabbit holes of learning.

Love thy toys; love thy magic.

Today we’re excited to announce the latest addition to the Basecamp team: Jay Ohms joins us as our lucky 13th programmer. He’ll be working with our mobile team on Basecamp for Android.

Android enthusiasts will know Jay as the one part of the duo behind Press, the popular Android RSS reader. Press arrived at a time when great design was hard to find on the platform. Jay’s focus on quality and eye for detail made Press a favorite and caught our attention, too.

After spending a week working with our Chicago-based Android team on a trial project we knew Jay, who also happens to live in Chicago (did someone bribe an alderman?), was a great fit. Jay makes us better on Android and we’re excited to show you what we’ve got in store for 2015.

Everyone, Jay; Jay, everyone.

Of the many axioms in the world of software, few rise to the occasion of Thou Shall Not Rewrite Your Application. Spolsky called it the “single worst strategic mistake that any software company can make” in his seminal 2000 essay Things You Should Never Do.

The Big Rewrite has been likened to all sorts of terrible things, but perhaps the most damning is its association with declaring technical bankruptcy. Basically, the only time it’s reasonable to embark on the terribleness of the rewrite, is when you’ve been profligate cowboy coder. When your mountain of technical debt is crashing down upon you.

So it’s the white flag, then. It’s giving up. Capitulation! The error of your inadequacy has finally caught up and will be taking you to the cleaners. Who the hell wants to be that sorry sob of a programmer!?

No wonder programmers are loathe to question the wisdom of NEVER REWRITE. Either they’ll reveal their own morally deficient ways, or they’ll be seen as apologists for others traveling that deviant path.

Now, axioms develop for a reason. Many a rewrite has been started and gone astray for all the wrong reasons. Either it truly was a result of technical bankruptcy, or, perhaps even worse, it was a result of perceived technical bankruptcy by a new team uninterested in learning why things became the way they are. As Spolsky quips, such a rewrite is basically the same software with more and different bugs!

But there are other types of rewrites. The one most dear to me is the “Don’t Try To Turn A Chair Into A Table” rewrite. It’s the one we committed when we launched the new version of Basecamp a couple of years ago. A full, start-over, everything-is-reimplemented rewrite of Basecamp because we wanted it to do different things.

Yes, Basecamp Classic and the new Basecamp both juggle many of the same ingredients of project management and collaboration, but they’re mixed together in very different curations. So while we could have gotten from A to B one carefully tested refactoring and commit at the time, it would have been a fool’s errand.

Starting over allowed us to question the fundamentals of how the application worked and how it was implemented. We were able to make leaps, not just skips.

A chair can indeed be turned into a table with enough effort. Both have four legs, and all you need to do is chop off the back of the chair, and somehow refasten it to the base to extend the surface. Oh, and maybe some new wood to raise the legs up higher. It can be done, but why on earth would you?

So we decided to leave the chair alone. People were using the chair, and still are – years after the new table premiered! And we got to build a beautiful new table that’s been serving us so very well for the last couple of years.

That’s really the bottom line here: We rewrote Basecamp from scratch and it turned out great! Better than great, actually. We got to leave well enough alone for people who had adopted and grown accustomed to Basecamp Classic, we got to offer a brand-new product to new customers that was the very best we knew how to make, and we got a greenfield codebase to enjoy as well. Plus-plus, would do again!

So what am I saying here? Rewrite willy nilly whenever you get blue over seeing a few modes of progress made cumbersome because of poor past decisions? Of course not. Embarking on The Big Rewrite is not a choice to be made lightly, but a choice it remains. It should be one of the options on the table.

If you’ve accumulated enough fresh ideas about how your application can be radically different and better, The Big Rewrite may very well be just what the carpenter ordered.

We’re looking for a programmer to lead us on Android and push us further into the platform. This is a unique opportunity: we don’t hire often! We’ve got a serious foothold in the ecosystem, and we want you to take us to the next level.

Here’s a little preview of Basecamp for Android right now:

We’re happy to welcome applicants based anywhere around the world. Our office is based in Chicago, but our team is spread out over multiple countries and time zones. You can work from anywhere! We’re so serious about working remotely that we even wrote a book about it.

Basecamp offers benefits for the long run, including: 4 day work weeks during the summer, an exercise and CSA stipend, a 1 month sabbatical every 3 years, maternity and paternity leave, and health insurance that covers children, marriages, and domestic partnerships.

Who are we looking for?

We’re looking for someone who lives and breathes mobile, and especially on the Android platform. Fluency in Android’s patterns and APIs is a must. (Half-hearted iOS ports drive us crazy too!) We would love to talk to a developer who has experience shipping applications with a team, or independently on your own projects.

What will you work on?

You’ll work on our mobile team to support and improve Basecamp for Android, side by side with our other programmers, designers, and QA team that enable our customers to get their work done better on the run.

You’ll join the our team of programmers who work on our Rails and iOS apps. Basecamp is the home of Ruby on Rails, and we’ll be happy to introduce you to our infrastructure. Part of being a programmer at Basecamp is our on-call rotation, where we help fix day-to-day issues for our customers using our products.

We also believe strongly in putting everyone on support, which usually happens around once a month. If you have some experience with Rails, that’s a bonus—but not a requirement.

How can you apply?

We love cover letters. They’re a great way to introduce yourself, but don’t be afraid to surprise us in other creative ways too. We want to see what you’ve built and shipped, so any existing applications on the Google Play Store that we could try out would be great to include.

We’ve filled this position. Thanks for your interest!

Our setup at Basecamp for testing our iOS apps is pretty neat. It (synonymously) involves Xcode’s CI Bots, but that’s easily the most uninteresting part of it. Here’s how we continuously integrate our iPhone and iPad apps at Basecamp and get build results into our Campfire.

Build your bot

This is easily the trickiest part. However, it is pretty boring. Once you’ve followed Apple’s tutorials to setup OSX Server and the Xcode service (which I will skip or lose pretty much everyone reading this for several hours), you just need to head to Product > Create Bot inside of Xcode.

I recommend creating an empty Xcode project first to just make sure everything is working – don’t start with your main iOS codebase. I named it “Placebo”.

We have some specific settings on our bots. Here’s a screenshot for each screen in the bot wizard, since there’s no way to share them outside of the Xcode walled garden. The first screen is the easiest:

Almost 2 years ago I wrote about our approach to building our first in-house native application. This week, we shipped version 2.0 of Basecamp for iPhone, which now shares a codebase with Basecamp for iPad. I’m proud to say this is our best iOS release yet. Give it a shot!

What’s changed? Everything. For starters, we’ve:

• Rewritten the app in Objective-C
• Banked on our hybrid architecture
• Shared a universal codebase between iPhone and iPad
• Reinforced our testing infrastructure

I’m happy to share the details on how we built and shipped the app. Let’s dig in.

Fragmentation isn’t just Android’s problem anymore.

Here’s the last 2 years worth of iOS and Android usage by operating system version for Basecamp, combining our native app usage and our mobile web views:

Fragmentation is the past for Android, but now it’s the present for both of the major mobile operating systems. My big question: will we see either platform be able to converge in the future, or is this the new normal?

These were made with Tableau by Noah, which is really fantastic. Noah’s fantastic too.

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.

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.