The Learning Journey

Obie Fernandez, the author of the now de facto Rails book, The Rails Way, have recently launched HashRocket, a Ruby on Rails consultancy with a unique business model:

Your application in 3 days or your money back

OK! That money-back part is of my imagination.

The reason I’m writing this is the “great” message on their homepage.

BUILDING A SUCCESSFUL WEB APPLICATION IS ROCKET SCIENCE

See the word “successful”? It’s a great marketing phrase that reflect how they perceive the value they give to their clients. Delivering a successful web application is indeed difficult, and HashRocket is conveying that message loud and clear.

Congratulations.

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.

I just need to get something off of my chest.

Some of the companies that I’ve worked for/with, rely heavily on their clients as the only true measure of performance. They would take client satisfaction as a reflection of how they themselves perceive their operations and businesses.

This is just plain WRONG.

Unless an organization have the established mechanisms and procedures that would identify problems before escalating into “customer dissatisfaction”, then they are on a decline path. Not only they need to identify problems, but, in order to remain competent, they also need to improve their internal operations. This can’t be done if an organization relies solely on their client to tell it how its operations are performing.

I’m not saying the customer satisfaction is not important. All I’m saying is that it should be “A” part of how you measure your company’s performance, not THE measure.

Customers might be pleased with what have been provided to them (in the form of a product/service), but, does that really mean it is the best that could be produced? A customer is never an expert at what an organization does. He’s only an expert at his own businesses/domain. Customers know the little about how a business (other than theirs) is managed, operated and what competitive advantage it has. That couldn’t be more true than in the cases where the traded commodity is as complex as the intellectual ability of an individual/team. In such cases, the only ones capable of establishing those performance criteria are those at the “producing” end, not at the receiving one.

Some organizations go to the uneducated extreme of hanging their employee performance on how their clients perceive those employees (yes, gentlemen, that happens). They sometimes even totally discard what those employees have provided. Their rule of thumb is “as long as there are no complains, they are on the right track”. This can never be furthest from the truth. I’ve been through projects where the products provided are seemingly functional from the outside. But, a simple look at the internals is enough to categorize them as “hit and run” projects.

How does a product/service that is “perceived” to be functional be in such demise? Why?

I belive the answer to the How part is not in the scope of this post (might rant about that in later post), but, I belive that the why answer is simple enough. There weren’t enough “interal” rules to identify what functional/satisfactory is. This doesn’t only apply to the delivered product, but rather the process through which that product was delivered.

In my opinion, the service delivery industry has yet to learn a great deal from the manufacturing industry. Ignoring the current environmental factors; The manufacturing businesses have been through extremes in order to survice and compete, not ONLY by meeting their customers’ needs, but also through the evolution of how they manage their own internal and external operations.

Phew.

Now I can sleep.

Pat Eyler from On Ruby has notified me that I won his Holiday Blogging Contest. My entry for generating a Rails site map was apparently the best Rails how-to in those posted. It won me 3 books from Apress.
This is my first online win EVER, and being it a Rails-oriented win, makes it even sweeter.

Thanks Pat. Thanks Apress.

As another great addition to this blog, I here introduce to you “Bilal”, our newest addition to the family.

Bilal was born on the 31 December 2007, at 8:10 PM in Calgary, Alberta, Canada, at this hospital. It’s funny that Bilal was meant to come to this world on the same day (31 December) as his beautiful sister.
He was post-due by 6 days and caused a lot of anxiousness to his mom and myself during the delivery. Alhamdulillah, our family is all pleased with what we are offered, and I hope I’d remain a good father and a loving husband isA.