Tuesday, August 12, 2008

A Note on Web Site Team Building (Part II)

For those of you who have been waiting patiently, I promised a decision, and in fact, here it is:

Yes we will go forward with the changes, but not until we complete a few critical team building steps and adequate preparation.

Here's the deeper story. It is true that many many MANY websites find the urge to "completely clean up their code" at various intervals, and in fact many websites do it every couple of years if not months.

This "re-coring" can avoid the topsy growth of serious website debt whose cost of interest cannot be underestimated - the so-called spaghetti code with which many are familiar...and if you are not yet, you probably get it by now.



















(http://southernfriedfatty.files.wordpress.com/2007/06/spaghetti-head.jpg)



BUT these very same teams almost always discover that several months after the MASSIVE effort, which promised a life of clean code development and smooth product rollout, they were right back to where they started - the framework was not as robust as their community required, one edit led to another, and BAMMM!























So what is it about re-coring that is so attractive?

What it really comes down to is a Human Factor of choosing the best beginning environment that the collective team feels most comfortable working within and then adjusting off that target for each major stage of growth. Therefore, here at LM the team is feeling a need to clean up the code, and so now they must decide collectively on a new framework. TEAM SELECTED. TEAM ROLLED OUT.

Next, we must create a proper estimate for the duration of this change. The rule of thumb is 3-4 times longer than the estimate, so we need to work hard to better understand the business logic of our own "crusty" code, before we put on the rose colored glasses of "1-day" code base conversions. Our team is going to do this and in so doing, they are likely to learn much about how to tackle and to speed any future conversion. The way they are planning to do this is to work the rollout of certain features under to old code base. Painful? Undoubtedly. Instructive? You bet.

After that, they intend to cross-train each other to roll-out discrete but fully functional pieces of the website under the recommended new architecture. These features are best done if and when compared to sections of the website created in the old code base. The difference in performance, speed of creation, reduction of error, and ease of unaided explanation, should be markedly noticeable, or the "waste of time flag" will be flown high and proud.

And finally, our group must rollout, as a team, sections of the newly coded site, one at a time versus tackling the whole site at once with one big key that we turn. 'Nuff said - this is to avoid major heart trauma for the whole team on the "rollout day".

Our team discussed this strategy today, and we agree that this is the best way to preserve a strong and vibrant code base and development team. Watch out for the LM web development team, they are growing stronger by the day, and our leader, who remains on safari in Africa, can breathe easy knowing that the lions may get him, but his team is here to carry forward a STRONG legacy of LM site development.

No comments: