The road not taken... really

Sometimes, despite the best - and highly committed - intentions, you have to take a step back and give up on a particular course of action.

One of the phrases that's stuck with me since the earliest OB (Organizational Behaviour) classes is 'escalation of commitment' - which, in its essence, means the pursuit of a failed cause simply because one has committed to it. You throw more resources at it, you ignore other priorities, you try your damndest... and yet, you may still fail because failure was all it was meant to be. And as in most cases where a little knowledge is the most dangerous thing, guarding yourself against this psycho-virus is as dangerous as it would be to ignore it. In your haste to absolve yourself of an escalation of commitment, you may well leave a problem unsolved right at the edge of its solution.

(On a side note: Metaphors tend to flow more freely towards midnight than at any other time. Hmmm...)

In my last post on July 29th, I had argued for (albeit against myself, proving once again that even when I win an argument, I lose!) adopting Yii. The arguments are perhaps still as sound as they are then - the framework is still a benchmark, it's a proven workhorse and stable and secure - but the experiences of battling with its steep learning curve has finally taken its toll on me. A slower coding speed at the initial stages was acceptable if there was progress; but to be stuck at the starting point itself, relearning the commands and parameters, the do's and the don'ts, for more than a week is asking for trouble. 

And that's led to some serious soul-searching. Should I invest in becoming an expert on Yii (and an expert you need to be, to take full advantage of its possibilities) or should I absorb the best and come up with a framework that I can use to speed up my prototyping? At some point of time, the answer became pretty obvious. Yii had to go. At the end of the day, Yii is just a framework (a very popular one, but still just a framework) in a world that has plenty of frameworks; it looks good on your resume, particularly if you have worked with a team where the collaborative learning would have been superior to picking it up by yourself. No regrets about this road not taken.

At the same time, the experience has not been completely fruitless. Working with MVC architecture has refined my coding and code-organizational skills, helping me hone ProPlan into a better, more flexible, more intuitive and lighter web-development interface. The shackles have really come off in the last 36 hours, with excitingly rapid progress on developing the CRUD/Form-maker module for ProPlan. The idea is to develop both the fundamental engine and it's value-adding components simultaneously, an approach that gives me the chance to keep testing our plug-and-play system continuously. Effective? Yes. Efficient? Getting there...

What else do I take away from this brief but meaningful liaison? One, it pays to do your research on these things before you start. Two, establish your benchmarks when trying out possible solutions - to guard yourself against that escalation of commitment and to keep evaluating your own adaptability. Just as short-term gains should not distract you from long-term investments, the tenure of these long-term plans should itself not be so long as to render it meaningless. It's a highly subjective measure, though... would you rather extend the deadline by 50% more (or even 10% or 20%) to develop the basic requirements with the promise that things will get better? Or would you rather try to finish off your version-1 well within the deadline and then use up another 10-50% of the project schedule for enhancements?

The trade-off you make... speaks volumes about the way you will handle your client's problems!