Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

Refactoring or Re-build - What are your experiences?

Nowadays the founders are trying to launch the startups as soon as they can, building quick MVP's orin 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"?

8 Replies

Roshan Diwakar
4
0
Roshan Diwakar Entrepreneur
CTO and Principal Consultant at Xtreme Automation Corp
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 areenamoredby 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
0
0
Joe Emison Advisor
Chief Information Officer at Xceligent
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
0
0
Christopher Silva Entrepreneur
CTO @ POSpulse
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
0
0
David Schreiber Entrepreneur
Founder
Joel Spolsky wrote an article on this many years ago that you may find enlightening:

http://www.joelonsoftware.com/articles/fog0000000069.html

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
0
0
Atanas Stoyanov Entrepreneur
Founder, CEO wootrader.com
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.
Joe Emison
0
0
Joe Emison Advisor
Chief Information Officer at Xceligent
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):
http://businessofsoftware.org/2015/10/david-heinemeier-hansson-rewrite-basecamp-business-of-software-conference-video-dhh-bos2015/


Faisal Memon
0
0
Faisal Memon Entrepreneur
iOS Department Technical Lead at Citrix ShareFile Quick Edit
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.
Jaswant Pujari
0
0
Jaswant Pujari Entrepreneur
Entrepreneur
While the re-factor or re-build is an engineering problem, you have to keep in mindthe 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 knowthat 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.

Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?