NEW: Organize your team in Close with Groups →
Business of Software 2015 Recap by Phil & Steli

Business of Software 2015 Recap by Phil & Steli

For Business of Software 2015 (BoS 15) Boston, I recently had the honor of speaking there and giving a sales workshop. Phil Freo, who leads product/engineering at Close came along with me, and here’s a quick recap of our favorite takeaways from the event - with lessons from the founders of Basecamp, Kalzumeus, and Balsamiq!

Slaughtering sacred cows

David Heinemeier Hansson (DHH), who created Ruby on Rails and founded Basecamp, spoke about rewriting your software from scratch and how he grew up on the paradigm of agile software development, which is all about being able to morph and evolve software one commit at the time while maintaining an eternal codebase.

Many years ago, Joel Spolsky wrote a famous essay on why you should never rewrite your software. In the essay, Joel argued that it would kill the organization and made a compelling case with the example of Netscape.

As you might have guessed, DHH is just the kind of guy to renounce the ‘don’t rewrite’ axiom.

Good reasons for not rewriting your software...

There are many good reasons to stick to your existing codebase but here’s the main one: your existing users don’t want you to change the software they’ve been using for years. They like the way it works.

Sure, they want some new features, bug fixes, improvements… but as soon as you strip out a bunch of features and make a more fundamental change to the way your software works, your users will revolt. To them, you’ve fixed something that wasn’t broken.

… but here’s why you should rewrite your software anyway

If you don’t fundamentally change your software every couple of years, your software will become ten year old software within the next ten years - even if you continuously improve upon it. New users will no longer be impressed by your solution, because it’s based on an idea that was great 10 years ago, not in there here and now.

Thus, every once in awhile, you need to rewrite your code from scratch.

As Peldi from BalsamiQ pointed out (pained body language included), dumping everything and starting from scratch is distressing. People who loved your software and used it for years will hate it now. You’ll have to make difficult choices and juggle conflicting opinions within your team as to which features to keep, which to discard, and which to add.

But it’s still the right thing to do if you want to stay on top as the world changes. Don’t be attached to, or held back by, the creations of your past.

Practical tips for rewriting your software from scratch

DHH shared lessons he learned from rewriting Basecamp’s codebase with a completely new data structure, which turned into a completely different product, offering no migration path at all.

  • When you launch a new version, keep running the old version.
  • Don’t force your users to upgrade to the latest version (Basecamp doesn’t even highly recommend running the new version - they just let their users choose). As long as there are people still paying to use the old version, let them.
  • For the new version, treat it as a new product.

Compete with the best ideas you have today, not with the best ideas you had 10 years ago.

Treat rewriting your software like woodworking:

“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.” - DHH, The Big Rewrite, revisited

Rewriting your software isn’t something that should be done lightly, but if there’s a potential to create a radically better version of your product, it’ll empower you to make leaps instead of steps.

How to not suck when recruiting

Recruiting, especially for engineers, is difficult. Make it a little easier by following the advice of Patrick McKenzie, creator of Kalzumeus Software and CEO of Starfighter.

  • If you’re giving a talk, don’t just add “we’re hiring” to the last slide of your presentation or your website.
  • Instead, be more appealing by discussing what you love about working there and how the people are great.
  • If you’re doing outbound recruiting, offer to help candidates skip part of the hiring process.

Let’s just say Phil and I had to delete our own last slide. Instead of viewing recruiting as a cut-and-dry process where you offer jobs and hope candidates apply, think of it as courting. You want candidates to fall in love with your company by showing them why you fell in love. Once they fall in love, treat them better than the other suitors (i.e. companies).

Use humor to close the deal

Here’s how Patrick convinced a big, unicorn startup in Silicon Valley to become an early customer for a new business that he’s building:

Patrick: “Do you know Steli?”

CEO: “Yes.”

Patrick: “Well, if Steli was here, Steli would never let you go without a firm commitment that you’re going to be using our software - so, are you going to be using our software?”

CEO: “This is so weird of you to say this. This is so not like you.”

Patrick: “Yes, that’s why I said Steli would say this. So, will you buy?”

The CEO thought it was super hilarious - and closed the deal with Patrick!

Don’t be afraid to use humor (or my name!) to close the deal.

Remain authentic to your vision

Giacomo “Peldi” Guilizzoni, the founder and CEO of Balsamiq, started a company with no intent of selling it. When the company reached 12 employees, he said “We finally have the perfect company size. We will never change it in the next five years.” He wanted to stay small - but then the money came along.

Peldi began going through acquisition talks with a famous unicorn startup offering a ton of money. For such a small team, the money would have been life-changing. However, the decision tore Peldi apart while the stress resulted in him developing a phobia. In the end, he decided not to do the acquisition.

While parts of Peldi’s talk were confidential, the main insights were not:

  • Sharing the acquisition process with family and friends can make it a better, and more authentic, process.
  • Everyone struggles. People can fervently blog about their principles and how they would never sell but - as the Balsamiq team experienced - after being offered money for an extended period of time, they can come very close to losing their way and selling.
  • Know why you’re doing what you’re doing. It’s very easy to forget if you’re blinded by a lot of money and VCs offering you a new vision of what you’re doing that’s newer, bigger, and better. No matter how grounded you are or how strongly you believe in what you’re doing - not even you are immune to going astray when VCs whisper sweet promises into your ears.

Listen to others but prioritize your own voice

When you’re at a conference, it’s easy to feel inspired. You’re surrounded by all of these amazing people with their amazing stories. They have everything you want and you want to get there eventually.

However, you have to realize that a year or two from now, they might be giving a talk about how none of that stuff panned out or was the right thing.

Be inspired and ask yourself if the advice is authentic but don’t try to change yourself and change your own vision or inner direction. Quite likely, that person will change their minds and then, you’ll be stuck with their old ideas.

Keep an eye out for a video of me speaking at the Business of Software 2015 and follow @steli and @philfreo on Twitter for more great insights!