Is this a good way to scale our product? | Hacker News Reader

Is this a good way to scale our product?

1 pointrealschool5 comments

I work at a start-up, they built there code base over 2.5 years before I arrived. As we have grown it has become clear that there are serious problems with the code/database/framework. Everyone on the development side is well aware of this issue and knows that something needs to be done about it if we are ever to successfully grow.

The lead developer built up the product with some obscure framework that was very immature, poorly coded and inefficient in its database calls. Various developers have expressed their concern and the lead has made the decision to rebuild the core of the product by remove the old framework and building a new one with 'the best parts of various other frameworks'. However he wants to keep most of the 'view' and 'controller' code from our current version of the product.

Has anyone else done this or seen this done when a long term solution was required but there was only time for a 'quick' solution?

How large is this code base?

If you guys plan out enough, a complete overhaul might be the best solution.

During your development you will have learnt so much that as a team you couldn't of had the forsight to know you were doing it wrong when starting out.

If your startup can maybe spare 3 of your best developers for the development of your new platform that might be a better way to go. There comes a limit in the evolution and growth cycle when you realise that you can't keep adding and you need a new clean slate.

A Second option might be to create your own DBAL. What is it about your data base calls that is innefficient. If possible, you might want to create your own DBAL with something like memcache paired with it in order to have frequent caching where possible.

If the developers are dragging their heels and really don't like their development environment, you could think of it as a nice overhaul to boost team efficiency.

We use memcache in a limited sense and have added caching to our mysql server to cut down on the thousands of queries our product makes a second (even with just 10 users).

Our lead developer is around, but the two other most senior developers both quit this month. We will have ~= 3 developers total.

I was under the impression that our solution was going to be a complete overhaul, but that isn't the plan.

Wow, sounds like my workplace - pretty much the same story, except the two devs who wrote the 300,000 line monstrosity are already gone (worst page record: a page with one topic and 300 comments generates over 10,000 - yes, ten thousand - calls to MySQL, AFTER caching).

In our case, we're squeezing in a complete rewrite of the codebase around existing client work using the old platform. We're writing it as a few separate services (authorization service, content service, front-end, reporting service, and administration front-end) instead of a huge, monolithic app. To do this in a decent time frame (a few months), we're adding 5 or 6 contractors to a 3-person dev team, leaving 3 other devs able to deal with the existing platform.

Hehe - to actually answer the question, though, the method you are describing might work with enough good planning behind it. Unfortunately, it doesn't sound like your lead dev is willing to do that. You will probably find that the amount of work required to fix the existing system is within a stone's throw of the work required to rewrite it.

I wouldn't call your described plan a "good" way of doing things, necessarily.

Personally I think its a horrible plan, but I want to get feed back from people who are more experience them me.

I think we should rebuild with an experience architect leading the way, but it doesn't seem that the company sees that a reasonable.

Reply on news.ycombinator.com