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!

The road (not) taken

One of the key issues when you are developing a product (as opposed to a custom-built solution) is that there is often no definitive guide that tells you the best route forward.

Consider a trip you are planning to take to a nearby, but unfamiliar, town. The destination is known; perhaps all avenues of travel have also been accounted for. But how sure are you that driving yourself from point A to point B is better than, say, hiring a cab, taking the bus or train or something else? Would it make sense to go from A to C before B, just because C to B might solve some future requirement of yours?

Therein lies the catch when you are working with something as wonderfully - and as infuriatingly - flexible as PHP. Having followed my own style for the past couple of years, it would be infinitely easier for me to start coding for ice-Labs the same way - knock off each module one by one, using my own filing, navigation and  processing systems - rather than spend (a lot of) time learning a new framework and then twisting my plan accordingly to execute it.

The catch, as I expect it, would happen later during the game when I will probably find myself redesigning the code as I go along, modifying it here and there; a bigger pinch would be the amount of time spent on re-coding for the same basic elements (anyone who's coded a form for updating an existing record knows the pain I am talking about!); further down the line, as the next-gen of my staff takes over the maintenance of this product, there must be a clear and coherent framework that's apparent to the slowest among them!

Contrast this with the implications of using a framework such as Yii or CodeIgniter. Most of my basic work is already taken care of, such as modelling the data, setting the flow of control, etc. With Yii, there is an even greater degree of automation that promises to make a lot of my work easier, a lot of it compressed into one-line commands that ties into the API of Yii. Salivating thought... until you realize that the price to be paid is reinventing the way you've usually done things.

That is not often a bad thing - and after all, hundreds of programmers around the globe would not be testifying for these frameworks if the promises remained unfulfilled. Yet, for every site built with frameworks, there are at least two or three or even five that are gloriously independent of any such 'box'... and in some cases, are the better for it. Do you really need to obfuscate your URL or make it searchable by SEOs and bots? For most applications where data security is paramount, the answer would be a resounding no.

There is a learning curve that is associated with the use of frameworks too. The time that you would have spent on re-coding/re-designing/re-using your work at a later stage, when doing it your way, is spent on picking up the rudimentary basics of the frameworks at the initial stages itself. And don't forget the hours that precede this step, hours spent on researching and comparing frameworks to arrive at the shortlist! (Often with no clear winners, GeekWorld being what it is - apples by any other name could be oranges still!)

The clincher for me was merely a matter of pragmatism. Pro-plan, slated to be the first release out of ice-Labs, is a small project in the larger scheme of things - and a large project in the smaller scheme of things. Had I done it my (complete) way, Pro-plan could have been live by now (except maybe for delays caused by Acts of God or my own sloth) - but learning something new is a price worth paying. Between CodeIgniter and Yii, the choice is surprisingly easy for a guy to whom one is as new as the other. Yii wins the vote for its scaffolding features and generators.

The road thus not taken is my own.

Will Yii be the Yiing to my Yaang? Only time will tell...

Till then... Yiip Yiip Yurray! :D