

Is this a good way to scale our product? - realschool

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.<p>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.<p>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?
======
chrisacky
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.

~~~
realschool
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.

------
Rust
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.

~~~
Rust
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.

~~~
realschool
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.

