No

on 24 Jan 12

Basecamp Next surely has the soon-to-be-released Cinco under its skin, right?

Michael

on 24 Jan 12

I’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 12

No, 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 12

DHH : 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 ?)

Another 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 12

The correct way to look at is is as a second piece of software, not a rewrite.

Ryan

on 24 Jan 12

This 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 12

WunderKit has landed. Let’s see what BC NEXT hast to offer.

Greg

on 26 Jan 12

Is Rails even used at all in Basecamp Next or just all Node.js?

DHH

on 26 Jan 12

Greg, 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 12

Over time, software builds up legacy. The old technology is baked in, and the roots of the product are so knotted that simply unwinding them becomes a massive undertaking. Think about trying to uproot a 250-year-old oak tree versus a two-year-old one.

But 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 12

Wow, 2002. Early adopter. Uhhhhhhhh

This discussion is closed.

About Jason Fried

Jason co-founded Basecamp back in 1999. He also co-authored REWORK, the New York Times bestselling book on running a "right-sized" business. Co-founded, co-authored... Can he do anything on his own?