REWRITE: Why Basecamp 3 is a brand new code base, the evolution of code, transcendent software, and executing your very best ideas.
Watched byDavidon October 12 2015.
There are8 comments.
Kevin
on 12 Oct 15
@DHH
Do you have any thoughts on your ability to Rewrite Basecamp every few years because ultimately, Basecamp is an extremely simply product (eg Todo list).
I mean no disrespect when I say that.
I just imagine however that if your company was instead building Order Management or ERP software, both of which are significantly complex, you’d far less options in rewriting your product and instead – technical debt would occur because the cost / time commitment to rewrite is far too much
DHH
on 12 Oct 15
Kevin, everyone else’s job always looks a lot easier. I share my experience and advice based on that experience. Apply as you see fit to your domain.
Oleh
on 12 Oct 15
@Kevin
We’re currently running ~100kloc ROR app. It’s quite complicated and has bunch of legacy and smelling code. New devs we hire can’t fix relatively simple bugs, b/c they usually miss some tricky not obvious thing “only elders are aware of”. We do try to refactor things as much as possible, but some of those things are large and core features and can’t be split into parts.
Few months ago we decided to refresh the UI. We started from relatively simple small part of the app: settings. It took roughly 4x more time comparing to our worst estimate and we ended up with adding new code/views aside and then removing old stuff.
That part of the app is really simple, clean and fast and we really love it.
So once we deployed, we started to think: “where should we start and how do we proceed to apply same UI to whole app”. We were thinking about 2 possible solutions: code freeze for an unknown period of time or complete rewrite. Neither seemed like a proper one. Now after this talk I think I know what to do.
Thanx @DHH :)
Bruno
on 13 Oct 15
The part I hate about this is that you’re the exception, not the norm.
Keep it up.
Jared White
on 13 Oct 15
Best talk by @DHH I’ve seen. You know, it’s funny—I have an (extremely small) platform I run with a handful of customers, and they’re all on different “revs” of the platform but it’s a single codebase and I essentially have glorified “if” statements in place to route people to different methods/views/partials so things sort of work for everyone. So far it’s been OK, but I keep wanting to do a major upgrade and marketing push and every time I start to think about how I’ll have to tiptoe around so many parts of the codebase my heart sinks and I don’t do it. So, essentially, my code has held me hostage and I can do longer be an entrepreneur. I feel the handcuffs on me. That sucks, especially since, as I said, I have only a handful of customers.
You’ve given me the courage to start over. Same basic type of product for same basic type of customer, but a fresh experience with a fresh knowledge base I can draw from in the design process. And I can keep the previous platform running so nobody hates me. I too have been haunted by the Joel quote but no longer. Thank you!
Lachlan Campbell
on 15 Oct 15
@DHH — This talk was fantastic. Really enjoyed it. Doing a rewrite was definitely something we were struggling with internally at Highrise (during my internship), because the codebase is old (2006-2008), yet we were a new team and wanted to keep positive momentum with customers. At Basecamp, you’ve had momentum for years, and the codebase has not gone stale in any way. Super interesting hearing about your story around rewriting/transcendent software and how long it took to finally embrace the idea of starting fresh.
Anthony
on 16 Oct 15
One thing I would say about the ‘cost to users’ of a change. If done a small amount at a time, and with good inline (‘Where did that button go? It’s now here.’) help, it’s much less disruptive than a bunch of changes all at once.
Dushan
on 18 Oct 15
Great, inspiring talks. Thanks! :-)
One comment: Basecamp is in the Project-Management-Business. Which means that customers’ projects are completed and new projects start. Thus customers can complete their old projects on the existing platform and start new projects on the new platform. Such a transition can even be a welcome chance to get rid of zombie projects etc. – A transition between platforms will be way harder when customers work on the same body of data the whole time, like e.g. with Highrise. In those cases you’ll need some serious support for data migration.
This discussion is closed.
About David
Creator of Ruby on Rails, partner at 37signals, best-selling author, public speaker, race-car driver, hobbyist photographer, and family man.
Kevin
on 12 Oct 15@DHH
Do you have any thoughts on your ability to Rewrite Basecamp every few years because ultimately, Basecamp is an extremely simply product (eg Todo list).
I mean no disrespect when I say that.
I just imagine however that if your company was instead building Order Management or ERP software, both of which are significantly complex, you’d far less options in rewriting your product and instead – technical debt would occur because the cost / time commitment to rewrite is far too much
DHH
on 12 Oct 15Kevin, everyone else’s job always looks a lot easier. I share my experience and advice based on that experience. Apply as you see fit to your domain.
Oleh
on 12 Oct 15@Kevin We’re currently running ~100kloc ROR app. It’s quite complicated and has bunch of legacy and smelling code. New devs we hire can’t fix relatively simple bugs, b/c they usually miss some tricky not obvious thing “only elders are aware of”. We do try to refactor things as much as possible, but some of those things are large and core features and can’t be split into parts.
Few months ago we decided to refresh the UI. We started from relatively simple small part of the app: settings. It took roughly 4x more time comparing to our worst estimate and we ended up with adding new code/views aside and then removing old stuff.
That part of the app is really simple, clean and fast and we really love it. So once we deployed, we started to think: “where should we start and how do we proceed to apply same UI to whole app”. We were thinking about 2 possible solutions: code freeze for an unknown period of time or complete rewrite. Neither seemed like a proper one. Now after this talk I think I know what to do.
Thanx @DHH :)
Bruno
on 13 Oct 15The part I hate about this is that you’re the exception, not the norm.
Keep it up.
Jared White
on 13 Oct 15Best talk by @DHH I’ve seen. You know, it’s funny—I have an (extremely small) platform I run with a handful of customers, and they’re all on different “revs” of the platform but it’s a single codebase and I essentially have glorified “if” statements in place to route people to different methods/views/partials so things sort of work for everyone. So far it’s been OK, but I keep wanting to do a major upgrade and marketing push and every time I start to think about how I’ll have to tiptoe around so many parts of the codebase my heart sinks and I don’t do it. So, essentially, my code has held me hostage and I can do longer be an entrepreneur. I feel the handcuffs on me. That sucks, especially since, as I said, I have only a handful of customers.
You’ve given me the courage to start over. Same basic type of product for same basic type of customer, but a fresh experience with a fresh knowledge base I can draw from in the design process. And I can keep the previous platform running so nobody hates me. I too have been haunted by the Joel quote but no longer. Thank you!
Lachlan Campbell
on 15 Oct 15@DHH — This talk was fantastic. Really enjoyed it. Doing a rewrite was definitely something we were struggling with internally at Highrise (during my internship), because the codebase is old (2006-2008), yet we were a new team and wanted to keep positive momentum with customers. At Basecamp, you’ve had momentum for years, and the codebase has not gone stale in any way. Super interesting hearing about your story around rewriting/transcendent software and how long it took to finally embrace the idea of starting fresh.
Anthony
on 16 Oct 15One thing I would say about the ‘cost to users’ of a change. If done a small amount at a time, and with good inline (‘Where did that button go? It’s now here.’) help, it’s much less disruptive than a bunch of changes all at once.
Dushan
on 18 Oct 15Great, inspiring talks. Thanks! :-)
One comment: Basecamp is in the Project-Management-Business. Which means that customers’ projects are completed and new projects start. Thus customers can complete their old projects on the existing platform and start new projects on the new platform. Such a transition can even be a welcome chance to get rid of zombie projects etc. – A transition between platforms will be way harder when customers work on the same body of data the whole time, like e.g. with Highrise. In those cases you’ll need some serious support for data migration.
This discussion is closed.