This has nothing to do with comparing 8 different frameworks.
It’s just to tell the horror story of one of our down-the-drain projects.
The client came with an old product that he needed to add new features to. The product does, what is best described as CRUD operations. Nothing challenging, nothing difficult. It maintains a set of data for various client in a certain business domain. Their business model (at least what they’re trying to do) is through ad and subscription revenue. They were trying to move the business forward through enhancing the provided service.
The only challenge can best be described as that the product was a pure mess.
It has been built using (last time I counted) 7 different Java frameworks, some redundant, some obsolete. Apparently it has been the greatest learning experience for few individuals. The product took 8 years in the making, 4 different teams (non remained with the project), 14,000+ files, absurdly normalized 100+ tables database, absolutely 0 documents, No unit/function/otherwise tests to reach its current state.
To give some example of code horror that we had to go through, some Java classes contained business logic, HTML code, display logic, data access mechanisms, hard coded urls. The objects were then instantiated from within JSP pages (with lots of other embedded Java business logic/code) and passed parameters and servlet controls.
This is not to mention the build scripts that took 3 hours to update code off of the CVS, then threw numerous errors during the “real’ build.
That’s in addition to the project tree which was in a state of absolute mess (40+ different individual modules, with some exact modules placed in different locations).
And have I mentioned the “wrapper” PHP application that was delivering a CMS-like functionality (another set of mess, with no cross-application awareness of any kind).
Again, the product didn’t do anything challenging. Just basic CRUD and a couple background processes.
Our initial attempt was, of course, to build on top of the insanely absurd code-base, but after few days, we’ve decided (us, client, operations) that it might worth to venture into a new platform, in order to make it easier (and cheaper) to deliver new business service and at the same time, incrementally migrate features into a more robust code base.
Few months into the making; including the client formulating his requirement and reverse engineering the legacy system, we had our first release of the new business features (including the integration with the original application, modelling 70% of the legacy schema, a streamlined version of few original functions, documenting finds of the original application).
Few more months of client acceptance testing (and repetitive requests from our part for a feedback), client vacations, and [seemingly] client running out of budget, the client finally came back to us deciding that our solution was not accepted.
I frankly didn’t know whether to laugh or cry.
Despite the fact that the client admits, in his own words, the original Java application is a bag of “s$%t”, he refuses any attempt from our side to tell him that his application is non-maintainable.
He decided (and probably promised by some other individuals) to monkey-patch the code base that he has. He, of course, threw our choice of Ruby into the bag of reasons not to pursue this further.
Although I can defend our decision to resort to an incremental migration, and taking Rails as our vehicle quite well, yet, I now believe that the choice of technology should be the least of his worries. The business decision of incremental migrations (or even rather a rewrite) remains the optimum choice in my opinion, whether it’s done in Ruby, Java, PHP or brain*^%&.
The moral of the story is: As long as you care, never be a door mat, insist on getting your ideas through, always believe that you’ve been hired not for your typing speed, but for your intellectual abilities and what they can bring to the business.
