Tuesday, July 18, 2006

Pragmatic Project Principles?

My latest project has some interesting challenges.  Firstly, like virtually all interesting projects the deadline is fairly determined.  It happens to be far away, which is good, but fixed nonetheless.  Next, the resources to meet the tasks are unfamiliar with the technologies we are using, they aren't formally trained in software engineering, and have existed in a culture of complacency for the last several years. Okay, so having resources that are barely competent and lazy is different but not insurmountable.  After all, the best solutions I've ever known have been created by lazy people to facilitate their laziness (and yes, I am known for being mayor of lazytown).  Lastly, it is run by formally trained, highly experienced consultants who have been thoroughly brainwashed and bamboozled into plan-driven methodologies (think waterfall approach and the like).

The main challenge with this is that plan-driven approaches revolve, by definition, around a detailed plan of tasks and schedule, hence the name.  Which works well in environments consisting of relatively known behaviors, requirements, and abilities.  For example, a team of consultants all similarly trained on a project with ample time to define and document the requirements in sufficient detail.  That would not be this project.

To embrace the uniqueness of the environment the approach followed must be capable of supporting the differing levels of resources and abilities, the ambiguous nature of the requirements, and a general resistance to behavioral change.  Simply put, when you have people whose performance you can't estimate, working on tasks that are not fully defined, you really won't have much of a plan to manage against.  And any plan you initially create will invariable fall apart under the speed of which changes are encountered. See Sun Tzu for details.

There are various techniques for operating under these types of conditions, after all we're not the first nor will we be the last to find ourselves in such tumultuous waters.  In following posts, I'll discuss some of these approaches which I have found to be especially effective.  They specifically impact the Document and Design phases of the 5-D Approach which I've discussed previously.

Saturday, July 01, 2006

They Really Did

Pretty much any rational person would understand that the most valuable thing to a software development team is the Source Code they are writing.  They want it protected.  They keep it safe, they respect it.  After all, it is the fruit of their labor.

On my most recent project I'm working with a group of developers over in India who are partnered with my engineers here in America.  For efficiencies sake, we agreed to host the master copy of the source code in India to make it easier for those developers. Evidently, this is giving them way to much credit.

Several times we'd come back in the morning and the items we had worked on (we being anyone in the US) had been deleted.  Vanished, gone, poof.  At the time we wrote this off to just configuration problems or accidents.  It was only a few files here and there, and mostly there were back-ups.

This past week we came in and the WHOLE THING WAS GONE! Someone had DELETED our entire set of source code and associated items.  There was nothing!  Hundreds of man-hours vanished overnight.  No reasons, no oops.  Just gone.  And what is worse, they tried to hide it!  They didn't call and say "Umm, guys..."  We had to find out for ourselves!  What a nightmare.

Long story short, this whole off-shore development thing is turning into a way bigger hassle than it's worth.  Welcome to my personal hell...