Scott, having worked on a few doozies, I agree with you that codebases
this bad never get fixed completely. But that's not to say that there
isn't sometimes a good business case for keeping them. A codebase like
that can be stabilized, triaged, and sectioned off (mostly through a
lot of hard work and a few tears). Once that's been done, one option is
that you keep the project intact and methodically work through the most
crucial sections, isolating and then refactoring piece by piece. Or
another option is that you set up a new app and share sessions with the
old app, writing greenfield code to incrementally take over and replace
the responsibilities of the old app. Or, maybe you move to a
service-oriented architecture and remove old code as it's replaced by
new services. All of these strategies have upsides and downsides, and
I'd say it depends a lot on the situation and the size and the
particular pathos of each application, like: how deep are the webs of
interdependencies? Are there tests? Are the gems merely outdated, or
are they also majorly monkey-patched? Is each JS fiefdom kept on
separate pages, or do they all load at once and vie for control? Lots
of variables go into determining just how difficult it will be to turn
the ship around.
The only strategy I've never seen succeed is to attempt to replace the
entire thing in one big release. Boy is it always tempting! But the
only thing that will accomplish is giving you a deep hands-on
appreciation for just how much business logic is tucked into the layers
of that big ball of mud :)
On Mon, Apr 18, 2016 at 9:34 PM, Alex Escalante
<[email protected]> wrote:
Hello. Many times I've been in situations like these before. They are
very hard on people. I learned a lot about handling complexity by
design, refactoring, testing… After all that experience I decided
the best way to deal with this kind of projects is by strategically
replacing parts of the system until you have it under your control.
Bug fixing can only take you so far.
If you depend on a system that is yours, you have to adopt a
continuous improvement process and treat it like a garden…
Alex Escalante
Web & Mobile Development For Hire
http://audelabs.com
On Mon, Apr 18, 2016 at 7:21 PM, Scott Olmsted <[email protected]>
wrote:
An insurance company started in 2009 has contacted me about fixing
their site and adding some features. The site was also started in
2009. They run the company through this Rails site, all the back
office stuff, plus some customer-facing pages about signing up,
making claims, etc.
It's Rails 3, and it's pretty awful. 50 models with all
possibly-related code. Many fat controllers with tons of business
and services logic. No service objects or anything similar. A few
tests, but they don't run. Three or 4 Javascript libraries
(Mootools!), dozens of JS and CSS files. Bootstrap 2. Hand-made
authentication. Can-can gem for authorization, but it's not used,
hundreds of lines of code for authorization are embedded in
controllers and views. Lots of jQuery, Prototype, and similar.
They want to ditch their developers because for each of the last
couple features they tried to add, something else broke. Clearly, it
would be a huge job to bring this site up to par, but what I'm
wondering is if it wouldn't just be better to toss it and build a
new site from scratch. Lift code where possible, but build anew.
My limited experience says that even with the best of intentions
codebases that are this bad never get fixed completely, it's just
too hard to make the business case for fixing so many things not
visible to the users and owner.
Has anyone ever seen a decision like this?
Thanks,
Scott
RailsRescue.com (rescue - ha!)
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google
Groups "SD Ruby" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google
Groups "SD Ruby" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google Groups "SD Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
