The signs are all here: There’s now an incubator on every corner, even your uncle is donning angel wings, and IPO expectations for Facebook are exceeding the hype for a new Twilight movie. But that’s all circumstantial evidence. What we needed was some public testimony to really put everyone in the right frame of mind.

Enter our trusted troubadour of bullshit, TechCrunch:

My best guess is that it is about to get crazy. And, only fools sit on the sidelines. Many strong and older entrepreneurs that I know are wealthy today because they made intelligent decisions during the dot-com bubble of the late ’90s. Success was not easy then, and it will not be easy now, either. But, the likelihood of a great outcome is much higher in a boom.

There are a lot of newly minted entrepreneurs that pursue their dream company in a halfhearted way. You may tinker with your idea while toiling at a day job. You may refuse to put in the work required to recruit the best talent. You might be afraid of launching an imperfect product. Or, you may put a mediocre effort into fundraising.

Let me translate: Dude, you’re going to miss riding this bull onto the bubble if you do not get on it RIGHT. FUCKING. NOW! Didn’t you see that someone just made A BILLION DOLLARS? Why wasn’t that you, lazy schmuck? Don’t answer that—there’s no time to look at the past, just quit your job, and come out here to the Valley post-haste. Sand Hill road just scored a fresh load of loot.

Now I get the basic psychology. Someone just won the billion dollar startup powerball and now everyone wants to make sure they bought a ticket for the next drawing. And why not? While the past season of tech IPOs has been full of duds, we still have the big baller Facebook coming up for a shot. And if red 32 hasn’t hit for the last few IPOs, it’s bound to do for this round. COME ON LUCKY 32!!!

But let’s calm down. Sooner or later, the market is going to sort these things out, and all will be right as rain. That’s evident with the Groupon fiasco. They’ve restated their accounting numbers endlessly and the stock has finally tanked. At the end of the day, the rules of accounting will blow through all the smoke and the mirror will show a face with no make-up.

Are you calm? Good. Now get ready to rage right back up. The new JOBS Act that was just passed with the help of a thousand VCs stomping it down the throat of Congress undoes all that. Matt Taibbi from Rolling Stones reports:

Ostensibly, the law makes it easier for startup companies (particularly tech companies, whose lobbyists were a driving force behind passage of this law) attract capital by, among other things, exempting them from independent accounting requirements for up to five years after they first begin selling shares in the stock market.

The law also rolls back rules designed to prevent bank analysts from talking up a stock just to win business, a practice that was so pervasive in the tech-boom years as to be almost industry standard.

Now isn’t that swell. Enable people with an extreme financial incentive to spin the truth, or outright lie about the numbers, a 5-year get-out-of-jail cover, and what are you going to get? JOBS, silly! Duh!

Buckle your seat belt, Dorothy, ‘cause Kansas is going bye bye.

When developers first discover the wonders of test-driven development, it’s like gaining entrance to a new and better world with less stress and insecurity. It truly is a wonderful experience well worth celebrating. But internalizing the benefits of testing is only the first step to enlightenment. Knowing what not to test is the harder part of the lesson.

While as a beginner you shouldn’t worry much about what not to test on day one, you better start picking it up by day two. Humans are creatures of habit, and if you start forming bad habits of over-testing early on, it will be hard to shake later. And shake them you must.

“But what’s the harm in over-testing, Phil, don’t you want your code to be safe? If we catch just one bug from entering production, isn’t it worth it?”. Fuck no it ain’t, and don’t call me Phil. This line of argument is how we got the TSA, and how they squandered billions fondling balls and confiscating nail clippers.

Tests aren’t free (they cost a buck o’five)

Every line of code you write has a cost. It takes time to write it, it takes time to update it, and it takes time to read and understand it. Thus it follows that the benefit derived must be greater than the cost to make it. In the case of over-testing, that’s by definition not the case.

Think of it like this: What’s the cost to prevent a bug? If it takes you 1,000 lines of validation testing to catch the one time Bob accidentally removed the validates_presence_of :name declaration, was it worth it? Of course not (yes, yes, if you were working on an airport control system for launching rockets to Mars and the rockets would hit the White House if they weren’t scheduled with a name, you can test it—but you aren’t, so forget it).

The problem with calling out over-testing is that it’s hard to boil down to a catchy phrase. There’s nothing succinct like test-first, red-green, or other sexy terms that helped propel test-driven development to its rightful place on the center stage. Testing just what’s useful takes nuance, experience, and dozens of fine-grained heuristics.

Seven don’ts of testing

But while all that nuance might have a place in a two-hour dinner conversation with enlightened participants, not so much in a blog post. So let me firebomb the debate with the following list of nuance-less opinions about testing your typical Rails application:

1. Don’t aim for 100% coverage.
2. Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.
3. You’re probably doing it wrong if testing is taking more than 1/3 of your time. You’re definitely doing it wrong if it’s taking up more than half.
4. Don’t test standard Active Record associations, validations, or scopes.
5. Reserve integration testing for issues arising from the integration of separate elements (aka don’t integration test things that can be unit tested instead).
6. Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!)
7. Don’t force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).

Given all the hundreds of books we’ve seen on how to get started on test-driven development, I wish there’d be just one or two that’d focus on how to tame the beast. There’s a lot of subtlety in figuring out what’s worth testing that’s lost when everyone is focusing on the same bowling or bacon examples of how to test.

But first things first. We must collectively decide that the TSA-style of testing, the coverage theater of quality, is discredited before we can move forward. Very few applications operate at a level of criticality that warrant testing everything.

In the wise words of Kent Beck, the man who deserves the most credit for popularizing test-driven development:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

We’re finally ready to unveil the API for the new Basecamp. The documentation lives on Github and we encourage developers to help us improve it with pull requests.

The new API covers most of what’s available in the web UI and whatever is currently not there, we’ll be sure to add in the future. You can create projects, add people to those projects, work the calendar, upload files, the works.

We’re really excited to see where people will take the API. Especially the Events API that allows you to poll for changes since a given timestamp. This should make it easy to have local notification style integrations and much easier for people who want to build synching services.

So have at it!

We started work on Basecamp Next back in April of last year. Initially it was just a tiny team: JF, JZ, and me exploring whether it would even be a good idea to rewrite Basecamp from scratch. That phase lasted about two months.

After the first two months, we were convinced that there was enough value to do The Big Rewrite. Basecamp Next did enough things differently that would be very hard to retrofit into Classic. So we committed to making it real. We then spent another two months or so fleshing out all the major functionality, still with just a small team. Sam and Ryan joined the game during that phase.

After that we slowly ramped up the team. Adding people here and there as there was enough decisions made to proceed implementing with. Everyone, more or less, was involved on/off taking the rough shell and making it solid. This phase took about four months.

The last two months we’ve been in crunch mode. Everyone in the company has been involved polishing, refining, and improving. This is also the time we spent building out our wonderful new calendar.

Take a look at the Github impact diagram to see the ebb and flow of the development process:

Or enjoy the light show of this commit animation:

It’s been a fantastic journey over the 10 months or so building an incredible version 1 of the new Basecamp. We’re finally at the end of the tunnel. Next week we’ll be ready to share it all with you.

There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton

Doing cache invalidation by hand is an incredibly frustrating and error-prone process. You’re very likely to forget a spot and let stale data get served. That’s enough to turn most people off russian-doll caching structures, like the one we’re using for Basecamp Next.

Thankfully there’s a better way. A much better way. It’s called key-based cache expiration and it works like this:

When we started working on Basecamp Next last year, we had much internal debate about whether we should evolve the existing code base or rewrite it. I’ll dive more into that debate further in a later post, but one of the key arguments for a rewrite was that we wanted a dramatic leap forward in speed — one that wouldn’t be possible through mere evolution.

Speed is one of those core competitive advantages that have long-term staying power. As Jeff Bezos would say, nobody is going to wake up 10 years from now and wish their application was slower. Investments in speed are going to pay dividends forever.

Now for the secret sauce. Basecamp is so blazingly fast for two reasons:

When the Series A check clears, most startups send out a bragging press release, the equivalent of flashing your grill. The VC backing is supposed to mean that the company has experienced hands in its corner. That it’s financially solid. A shoe-in for a puff profile piece in a magazine. Eligible for lunch conversation in Silicon Valley.

But if customers actually think about what a venture capital injection entails, it’s not all California Love. The company’s cash concerns might have (temporarily) vanished, but they’re replaced with a new list of problems. As a user you might be looking at any one of the following:

1. The Pivot
Sure, the product as described today sounds great, but if that hockey-stick growth pattern doesn’t emerge in six months, the product you wasted your time and money on might quickly turn into something else entirely.

2. The Talent Acquisition
Big companies like Google love to buy small bands of developers their VC friends tell them about (the risk easily triples if said band comes with Stanford or MIT pedigree). When the developers behind the app are acquired for their “talent”, you can expect a “sunset” to follow soon thereafter. That combination is the perfect euphemism for fuck the app and fuck the users.

3. The Runway
They don’t call it venture capital because you’re supposed to put it back in the bank. No, fool, that green gots to get spent. The quicker the better. So while $10 million dollars sounds like a lot, it might only just buy a company 12 months of runway. You know, once the swanky office in San Francisco has been decorated and the 100 programmer rockstars, designer ninjas, and bizdev suits have been bought.

4. The Pressure Cooker
Once a company takes millions of dollars of other people’s money, they’re instantly under extreme pressure to perform LIKE A TIGER. This kind of pressure can easily lead otherwise decent people to do indecent things with your data, your privacy, or anything else you hold dear. Because the scoreboard has already been set: winning means blowing it out of the park. And hey, sometimes a playa gots to cheat a little to make the magic sparkle, if you know what I’m saying.

5. The Acquisition Graveyard
If the product is strong enough to prevent a talent acquisition, you earn a few more years of fun and games before the product acquisition is likely to happen. With great fanfare some big company will announce what awesome synergies are in store now that the youngsters have “access to all the resources they need to take it to the next level”. The founders will spend two years on “integration” with the acquiring company’s legacy systems, and then – wait for it – their golden earn-out handcuffs will unlock and they’ll be long gone, along with any chance of the product ever getting better.

Of course, every now and then the clock that’s stopped tells the proper time. The fantastical success story somehow ends up being enough to swallow a hundred bad ones, so the crowd still cheers. See, world, we were there when this wee little lad got his first series A round and just look at him now!

Don’t fall for it. Given the odds involved, if you’re a user, or worse yet, a customer of a product, and the company behind it announces venture funding, the proper response is aahhhh, shiiiiiit.

One of the most pervasive myths of startup life is that it has to be all consuming. That unless you can give your business all your thoughts and hours, you don’t deserve success. You are unworthy of the startup call.

This myth neatly identifies those fit for mission: Young, without obligations, and few if any extra-curricular interests. The perfect cannon fodder for 10:1 VC long shots.

They’re also easier to rile up with tales of milk and honey at the end of the rainbow, or the modern equivalents, “compressing your working life into a few years” and “billon dollar waves”.

But running your life in perpetual crunch mode until the buy-out or bullshit-IPO fairy stops by your door is not surprisingly unappealing to lots of people.

The problem is that most “exciting new company” lore is intermingled with that of Startup Culture™. This means it’s hard to find your identity when it doesn’t match the latest company write-up of How Those Crazy Kids Turned VC Millions Into Billions!!!

Most people will look at that and say that’s not me. I don’t have 110% to give. I have a family, I have a mortgage, I have other interests. Where’s my place in the startup world if all I have to give is 60%? What can putting in part-time give?

The good news is much more than you think. The marginal value of the last hour put into a business idea is usually much less than the first. The world is full of ideas that can be executed with 10 to 20 hours per week, let alone 40. The number of projects that are truly impossible unless you put in 80 or 120 hours per week are vanishingly small by comparison.

This is of course nothing new. We’ve been playing this bongo drum for years. But every time I see people crumble and quit from the crunch-mode pressure cooker, I think what a shame, it didn’t have to be like that. It’s the same when I read yet another story about someone who won the startup lottery, and the stereotypical startup role model is glorified and cemented again.

It’s almost like we need another word. Startup is a great one, but I feel like it’s been forever hijacked for this narrow style, and “starting a business” just doesn’t have the sex appeal. Any suggestions?

It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.

Chrome ushered in a new era of the always updating browser and it’s been a monumental success. For Basecamp, just over 40% of our users are on Chrome and 97% of them are spread across three very recent versions: 16.0.912.75, 16.0.912.63, and 16.0.912.77. I doubt that many Chrome users even know what version they’re on — they just know that they’re always up to date.

Firefox has followed Chrome into the auto-updating world and only a small slice of users are still sitting on old versions. For Basecamp, a third of our users are on Firefox: 55% on version 9, 25% on version 8. The key trouble area is the 5% still sitting on version 3.6. But if you take 5% of a third, just over 1% of our users are on Firefox 3.6.

Safari is the third biggest browser for Basecamp with a 13% slice and nearly all of them are on some version of 534.x or 533.x. So that’s a pretty easy baseline as well.

Finally we have Internet Explorer: The favorite punching bag of web developers everywhere and for a very good reason. IE represents just 11% of our users on Basecamp, but the split across versions is large and depressing. 9% of our IE users are running IE7 — a browser that’s more than five years old! 54% are running IE8, which is about three years old. But at least 36% are running a modern browser in IE9.

7% of Basecamp users on undesirables
In summary, we have ~1% of users on an undesirable version of Firefox and about 6% on an undesirable version of IE. So that’s a total of 7% of current Basecamp users on undesirable browser versions that take considerable additional effort to support (effort that then does not go into feature development or other productive areas).

So we’ve decided to raise the browser bar for Basecamp Next and focus only on supporting Chrome 7+, Firefox 4+, Safari 4+, and, most crucially, Internet Explorer 9+. Meaning that the 7% of current Basecamp users who are still on a really old browser will have to upgrade in order to use Basecamp Next.

This is similar to what we did in 2005, when we phased out support for IE5 while it still had a 7% slice of our users. Or as in 2008, when we killed support for IE6 while that browser was enjoing closer to 8% of our users.

We know it’s not always easy to upgrade your browser (or force an upgrade on a client), but we believe it’s necessary to offer the best Basecamp we can possibly make. In addition, we’re not going to move the requirements on Basecamp Classic, so that’ll continue to work for people who are unable to use a modern browser.

Basecamp Next, however, will greet users of old browsers with this:

As we announced at the beginning of the month, we’re always on a mission to improve our uptime. Inaccessible apps are the cause of much frustration and users don’t care whether that’s because they’re scheduled or not.

While publishing our own uptimes have been a great step towards getting everyone in the company focused on improving, we also wanted to compare ourselves to others in the industry. So since December 16, we’ve been tracking five other applications through Pingdom to compare and contrast.

The goal is to have the least amount of downtime and here are the results from the period December 16 to January 31:

1. Github, down for 6 minutes
2. Freshbooks, down for 14 minutes
3. Basecamp, down for 16 minutes
4. Campaign Monitor, down for 21 minutes
5. Shopify, down for 1 hour and 53 minutes
6. Assistly (now Desk), down for 6 hours and 46 minutes

Congratulations to Github for the number one spot on the list. We are definitely going to be gunning for them! We’ll publish another edition of this list in a month or so.