I hear it all the time, "Our offshore team members are having a heck of time meeting our project goals for time and quality". But are you to quick to blame the new people when it's old code that is actually at fault?
Consider the following little history:
An application I had inherited used EHCache to reduce load on Database by storing application defaults. It was optimized to preload all Caches at Server startup time. As a result the code has always been a little slow to start up, what with 62 separate objects, each configured as its own independent cache loader.
The real pain began once the company added new global resources to the project, the offshore team members were consistently missing deadlines, and quality, well ... it left us 'underwhelmed'. I'm embarrassed to say this state of affairs lasted 6 months. Until one day - adopting some agile team practices, I chanced upon the real root of the problem.
Turns out this DB chatty load process could take up to ONE HOUR to load all 62 caches for the offshore team! Suffice it to say, it's probably unreasonable to expect a highly productive developer when the developer can hope at best to confirm only 4-5 changes per day...
New Lessons to Live By?
* Make time with sit with new team members as they integrate with your code, new eyes will reveal old problems!
* Demos don't lie, I'm sure the offshore team had mentioned "things ran slow", too bad we had accepted "slow" in the US side.
* Test network latency early and often, it is a hurdle you can't just throw hardware at!
* Code needs unit-tests. Unit tests would have forced us to design for DB independence, improving both US and offshore productivity for incremental changes to the 'legacy code'
Friday, December 31, 2010
Subscribe to:
Posts (Atom)