Refactoring or Re-build - What are your experiences?

Christopher Silva CTO @ POSpulse

January 23rd, 2016

Nowadays the founders are trying to launch the startups as soon as they can, building quick MVP's or in some cases the investor provides the technology, like Rocket and Project A, and normally during 2 years (average) they care more to grow the business than with technology,

At some point, the company just realize that the technology is the bottleneck to continue growing (whatever reason) and then start to care about it.

I think we don't need to say, but stop to support current platform is not an option and sometimes as small startup you don't have budget and a big team as Spotify or  Soundclound :)

So, real and classic scenario created, what approach do you prefer to deal with this "problem"?

Roshan Diwakar CTO and Principal Consultant at Xtreme Automation Corp

January 23rd, 2016

The answer always is - it depends.

But, realistically, the approach to it should be scientific.

"At some point, the company just realize that the technology is the bottleneck to continue growing"

This is a hypothesis, an opinion with no data to back it up.

What exactly is the bottleneck? Can't scale users? Can't deliver features quickly? Too many complaints? Low developer morale? Expensive Support/Operations?

How is the new Re-build going to solve this? Can you build a small feature to prove it?

Lot of times, a re-build is proposed because we are enamored by the new technology. We want to run away from working from 'legacy' code. But, if you aren't adding any proven business value, re-building is a risk 

If you are convinced a re-build is required. I would first work on separating/splitting the services, and then re-build a non-essential part.

Joe Emison Chief Information Officer at Xceligent

January 25th, 2016

While that Joel Spolsky article is in the canon, it's important to note that software development has changed substantially since he wrote it, and I do not view it as being as canonical as it once was.

First, what customers want is substantially different now than in the past, so the idea that you have important IP locked up in your old code is less true--your customers want high availability (24/7 operations) and more consumer-centric interfaces, and if your old code base lines up with a very different set of assumptions about your customers, then rewriting is required.

Second, software development practices (specifically, Agile [done correctly, which most people do not], including being agile and customer-centric on the product side), and tooling (like modern JavaScript frameworks and services like Algolia, Cloudinary, Firebase--even SquareSpace and Shopify) have made rewriting certain kinds of software much, much faster.

It's worth reading this counter-piece to the Spolsky one by DHH (equally famous and respected in his own right):


January 25th, 2016

While the re-factor or re-build is an engineering problem, you have to keep in mind the associated business problem. The answer should be based on a few fundamental questions you ask yourself.

Why?    To fix Design or code problem related to function or performance ?
        Design problem will probably lead to rebuild, figure it out early, not mid air.

What?   To fix underlying Data structure,  Core logic or  UI / UX ?
        Hope your application architecture is modular enough to allow changes in each layer  independently. Refactor if you CAN Rebuild if you MUST
        It takes a lot of users actively using a system for it to mature
        A rebuild pushes all the mature code out the window.

Who?    Is the change necessary for the User or yourself
        If the change is necessary for yourself then the user should not even know that you switched out the entire underlying hardware and software.
        If the change is to address user complaints then consult with the major users  and make sure you include all the necessary changes before the trek.

Of course, this is assuming you have paying users that you do no want to lose or impact negatively.

If your system architecture allows making changes to the three layers
    UI/UX, Logic and Data independent of each other then - REFACTOR
If it does not and you will lose customers unless you do something then REBUILD, do not procrastinate.

Joe Emison Chief Information Officer at Xceligent

January 24th, 2016

First, it depends upon whether you actually have users. If you don't have users, then you don't actually have a product.  It's unclear from your description whether you're rebuilding/refactoring in response to a lack of adoption.  If you don't have users, and you need to change the application, and you think the code is a mess, then you should probably start over. And build it properly, with good test coverage and all that.

If you actually have users, before you refactor or rebuild, I would strongly recommend building a fairly complete feature-test suite against your current code.  It's going to be the only way to make sure that you don't badly disrupt your users when you deploy different code (either rewritten or refactored). It's also going to keep your code in better shape for the future, so you don't run into this situation again (or at least less frequently).  Once you've written out the test cases, you can approach fixing code to meet each test from a perspective of "do we edit existing code, or do we rewrite existing code?" 

You might even--after writing the feature tests--realize that you should switch stack components, in which case you'd be rewriting those pieces.  But having the tests is a wonderful way to figure out how you're going to handle rewrite/refactor.

Finally, if you're talking about all this ex ante, where this is actually a planned idea that you're going to write a bunch of crappy code and then have to rewrite it or refactor it, you're making a big mistake.  A great architecture/base can survive (and even thrive) with mediocre developers, but a crappy base will not work well with even the greatest developers.  Spend the time initially to set up your application so that you have good conventions, style, test coverage, etc. This will dramatically decrease your long-term costs.

If you say: "I don't have the time or money to do the architecture properly at the beginning", then don't try to write software.  Build axure or invision click-throughs, or heavily customize SquareSpace or Wordpress, expecting to actually start real development with real programmers once you have the money to do it right.  (And the "time" argument is false--good developers go much faster with test coverage and good architectures).

Christopher Silva CTO @ POSpulse

January 24th, 2016

Thank you for the answer, guys.

The thing I agree is, depends on the case. In some projects, we did a refactoring, cleanup removing lots of "dead" code, writing functional and unit tests and creating adapters for the new features. Normally, I prefer the refactoring because u can go step-by-step and decrease the impact to the end user.

For me, when a team decide to go to rebuild way, normally some functionalities are forgotten, this is my experience.

David Schreiber Founder

January 24th, 2016

Joel Spolsky wrote an article on this many years ago that you may find enlightening:

Also, a comment on Roshan's point. It's good to make your development decisions based on measurement, but it's very difficult to measure developer productivity in general, and impossible to measure it with any sort of scientific rigor. I've worked at companies where the processes and architecture were terribly wasteful and obviously inefficient, but because management couldn't figure out how to quantify them on a spreadsheet, the (real) costs were ignored and the problems were politically very difficult to fix.

Atanas Stoyanov

January 25th, 2016

Chris, in most cases refactoring - building anew will introduce a lot more issues and take a lot longer than aniticipated. 

One case for rewriting - when you change the platform - for example a windows app to a web app.

Faisal Memon iOS Department Technical Lead at Citrix ShareFile Quick Edit

January 25th, 2016

The are two quite different bottlenecks in play here preventing growing the business.

First is the 'google type': they kept scaling the business exponentially so the fundamental algorithms and approach had to be thrown away to stop search or ads blocking the growth of search queries.  They refactored their platform into a set of well-defined services in the back-end, and then would re-write new implementations that provided the needed services but at a greater scaleability.

Second is the 'repairing wounds type'.  When you work on software and apply fixes to get better correctness, the code inevitably starts looking tricky and complex.  Engineering time doing maintenance then slows development time of new features -- creating a staff resource bottleneck for growth.  In those cases, refactoring is like 'healing the wound'.  What I find works best is if you add a feature, refactor what you last worked on, then add another feature, refactor what you worked on, etc.  This yin and yang keeps technical debt in control whilst allowing you to move forwards.

From a commercial perspective this is what I have seen: big company with a brand buys a small player, rebrands the goods and immediately you get 2x sales.  Then engineers work behind the scenes to unify the new offering with the other products.  You have mixed success.  Then the next generation is conceived, where you pull together the learnings of existant and newly acquired products to make a third product -- this is potentially a re-write of certain components.

This is "good" - its the reality that startup mode is proving the business with limited oxygen; technical debt is more acceptable.  Once business is pulling in cash, the focus can move to engineering it right given its now a cost spread over a larger customer base.

Another angle is open sourcing non-core parts of your infrastructure.  Its like shining  sunlight.  It allows people to clean up and restructure with everyone sharing the efforts and benefits.  Something about the public nature of it brings people's game up.  Its not a magic bullet but often a good direction to take.