The Startup
Published in

The Startup

Renovate or Rebuild

Why our drive to constantly build new startups is like tossing away hundreds of years of urban design.

I am a bit of an architecture nerd, several friends were architects at uni and I used to love helping them with model building all-nighters. Several years ago I got the chance to design and build my own house from scratch.

The house that Angus built

I like building analogies for software products, they don’t always fit because the software is, well, soft, but they are surprisingly useful when looking at legacy software products, which I’ve worked on a few times.

So consider the choice between renovating an existing house, or knocking down and rebuilding it. With software products, we can face the desire to build something new, in a startup perhaps, or to choose to enhance an existing legacy software product.

If we only ever build houses from scratch then we waste. Waste materials, waste effort, waste history and destroy their legacy. When we renovate houses we reuse what is already there in order to create something new. It sometimes wastes time and money, because a knockdown/rebuild process can be faster/cheaper, but it also requires us to carefully consider what we can reuse, repurpose and make more of. It can be done superficially, but even that makes something out of the character of the old.

When I built my house, one of the things I loved doing was having the chance to establish the feel of the main living area — making it open and airy, capitalizing on the great view out the back and minimizing views of houses to the sides. However, I also had to spend time and money on-site drainage and stormwater concerns (which really matter in Sydney!).

Peace and calm

Startups have to do the site drainage and stormwater plumbing work that mature organizations with mature products already have. Sometimes that brings with it baggage, a legacy of poor architectural decisions, ways of thinking and working that don’t make sense (like a SaaS contract referring to software licenses). But there are lots of advantages too, mature HR policies, established contacts with regulators or suppliers that help boost the work. Startups need everything anew and often waste a lot in doing that rework — or they borrow from their VCs or investors, sometimes bringing along a similar set of baggage.

While it can feel like more effort to change an existing organization, the rewards for success are much richer. It brings people on the journey of change rather than always discarding them. Sometimes jobs are lost along the way, just as a renovation may rip down a wall or strip out fittings, but overall it encourages reuse, retraining, repurposing to a better end.

Startups often like to say they are disrupting the existing status quo. Disruption for the sake of it is just another form of waste. Disruption to challenge entrenched imbalances of power, value, knowledge is more worthwhile. Often the greatest disruptors are leaders in an industry that choose to self-disrupt and thus reinvent themselves.

One of my favorite authors when it comes to business disruption as a topic is Steven Sinofsky, who has written much about how Microsoft and others have been disrupted by startups, other vendors and themselves. However, back in 2015, he referenced a brilliant New Yorker article by Jill Lepore titled The Disruption Machine: What the gospel of innovation gets wrong that skewers Clayton M. Christensen’s well-known book “The Innovator’s Dilemma”.

Disruptive innovation is a theory about why businesses fail. It’s not more than that. It doesn’t explain change. It’s not a law of nature. It’s an artifact of history, an idea, forged in time; it’s the manufacture of a moment of upsetting and edgy uncertainty. Transfixed by change, it’s blind to continuity. It makes a very poor prophet.

Her point is that Christensen’s work is based on fairly shaky ground, a bunch of hand-picked case studies, many of which don’t stand the test of time. It’s not that disruptive innovation didn’t happen, more that it was not a silver bullet that guarantees success. It’s a great explanation of what happened, but a lousy predictor of what will happen.

A few times in my career I have been faced with picking up a legacy software product and being asked to manage it. In each case, it has always been tempting to throw in the towel and declare that nothing short of a major rewrite will get us the business results desired. In other words, to rebuild the solution with modern architecture, design sensibility and, of course, a user-centered design approach to deciding what really needs to be in the product.

I have come to the conclusion that this is rarely that useful. Usually because:

  1. It’s not feasible — there are rarely enough resources for small changes, let alone a major rewrite.
  2. Your best developers will get absorbed building frameworks and patterns, and event handlers and … not creating features.
  3. You will lose all the effort that was previously spent in coding around the weird real-world issues that created bugs in the old software (“oh yeah, that was to handle weird variant PDF formats during rendering”).
  4. It brings your users, and in an enterprise world your choosers, along for the ride.
  5. Joel Spolsky said not to.

Of course, it isn’t so easy to reuse old code. As I mentioned with the renovate scenario above we must “carefully consider what we can reuse, repurpose and make more of”. However, that can lead to surprising discoveries, especially when you ask customers what you can afford to demolish from their legacy software. In my experience, it takes time and determination, because things never change as fast as you want it to until suddenly they do.

In the words of Bill Gates from his book The Road Ahead:

We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction.

Finally, it is sometimes right to rebuild rather than renovate.

In my case I had an empty block of land, so nothing existing to use — in your case you may have an existing software product that really does need to be replaced, or an entirely new customer need to fulfill.

Just make sure you take the time to consider your options and the real cost of going either way.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store