Why we're building a whole new Basecamp
My latest Inc. article explains why we’re building a whole new version of Basecamp from scratch. Sign up for an invite to the private beta.
You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !
My latest Inc. article explains why we’re building a whole new version of Basecamp from scratch. Sign up for an invite to the private beta.
No
on 24 Jan 12Basecamp Next surely has the soon-to-be-released Cinco under its skin, right?
Michael
on 24 Jan 12I’ll be switching over as soon as possible.
Deltaplan
on 24 Jan 12“Dumb question” : when Jason says “Users will be able to switch to the new Basecamp or stick with the Basecamp they are already comfortable with.”, does it mean that each and every individual user will be able to choose the Basecamp version that he prefers (or maybe the one that works the best, depending on his bandwidth for example), or will it be a choice given to each Basecamp account administrator, but that has to be done at the whole account level ?
DHH
on 24 Jan 12No, Next is not based on Cinco. There are shared elements on some areas, though (like some use of Backbone, Eco, etc).
Deltaplan, you can migrate on a per-account basis and within that on a per-project basis. The two versions are not just different UIs, though, so you have to keep individual projects in one account or the other.
We’ll post much more detail about all this shortly.
Deltaplan
on 24 Jan 12DHH : so what it will look like, if I understand you correctly, as the account owner and administrator, I’ll be able to create a “new Basecamp evaluation project” (aka sandbox project), migrate that particular project to the new Basecamp, so that the users of my Basecamp account can have a look at it, try the new features, see by themselves what has changed, and if they are ok with it then decide to migrate the “real” projects to the new Basecamp later (and I suppose this migration will be irreversible, for a given project ?)
MC
on 24 Jan 12I really enjoyed the Inc. article on the reasoning behind the rewrite. But it reminded me of a blog entry (cited from Chad F.) that David published a number of years ago: http://david.heinemeierhansson.com/posts/13-thinking-about-the-big-rewrite. It might make an interesting blog post to tie the two together.
DHH
on 24 Jan 12Deltaplan, that’s a reasonably accurate description. Things are still a tad influx and we’ll reveal all the details shortly though. But the general gist is right.
MC, I was the biggest opponent of this idea starting out ;). It took a few months of spikes and exploration work to convince me that this was the exception. But convinced I got.
Robert
on 24 Jan 12@MC: It seems 37S has an Apple-like mentality (which may, or may not be a good thing, depending on your perspective).
“This thing/idea is unnecessary/wrong. Until we say it’s necessary/right. Then it’s the best thing ever.”
Vis-a-vis rewrites. Vis-a-vis “never hiring an employee who doesn’t use Apple”. And a few other examples from recent times.
That being said, I’d definitely be curious to hear about how the rewrite goes.
Amaury Bouchard
on 24 Jan 12Another interresting link: Joel Spolsky saying that rewriting code from scratch is the single worst strategic mistake that any software company can make.
http://joelonsoftware.com/articles/fog0000000069.html
From my own experience, I would say that rewriting from scratch is often a tempting trap that must be avoided. But somethimes, in very special occasions, it’s the best move ever.
Michael
on 24 Jan 12The correct way to look at is is as a second piece of software, not a rewrite.
Ryan
on 24 Jan 12This isn’t going to work.
Oh, the new Basecamp might be great, that’s not what I mean, what I mean is:
Pissed off customers are going to be pissed off. So you’re letting them use the old version for a while, so what? Now they’ll “grumble” (as you put it) about being “abandoned” rather than about being “forced to upgrade.”
They know you’re not going to maintain the old code indefinitely, or fix what they consider the “real” problems, so they’ll still be pissed, and if they don’t like the new version they’re still going to cancel eventually.
In the meantime you’ve got months and months of supporting customers working on what are essentially two different products, when you could be supporting them on one. Multiply this extra cost by the number of places where Basecamp touches your other products, and where Basecamp instances can touch one another.
The worst part about keeping a “Classic” view around isn’t that it’s a sort of deception of your customers, who know that these sort of legacy products always die. It’s that it’s a sort of deception of yourselves. Instead of being forced to reconcile your new version with the expectations of your old users, as you would with one version, you get to punt with “those people can use Classic.” Which of course, long term, they cannot.
Oscar
on 25 Jan 12WunderKit has landed. Let’s see what BC NEXT hast to offer.
Greg
on 26 Jan 12Is Rails even used at all in Basecamp Next or just all Node.js?
DHH
on 26 Jan 12Greg, Basecamp Next is all Rails on the server side. Node is great, but not for this type of application and not for how we build them. We’re all running Sam’s Pow server locally, though, and that’s made in Node.
Robert Sullivan
on 27 Jan 12But it isn’t a 250-year-old oak, it’s an eight year old oak. Which leads to my next question, or perhaps, hypothesis. I’ve always wondered about the Agile processes 37 signals follows when building software. From what I can gather, an idea goes from HTML to code. Minimialist Agile process are followed, i.e. “just enough documentation”, and collaboration is via various tools like Skype and 37 Signals own tools. It is a successful product so this process works, despite my scepticism over a seeming lack of strict processes you might find at other shops. I agree that there are always times where, due to technological or environment (outside world) changes, it is easier to start from scratch. Microsoft did this with Windows NT. However, I don’t see those same forces applying here. It’s still Rails, still a Cloud app, etc. Therefore, my hypothesis is this – there is a tradeoff in which the ability to quickly apply changes with minimum “friction” leads to code that is legacy code with a short life, in which “old technology is baked in, and the roots of the product are so knotted that simply unwinding them becomes a massive undertaking.”
Pete
on 27 Jan 12Wow, 2002. Early adopter. Uhhhhhhhh
This discussion is closed.