Blah.Blah.Blog

However, this time I'm attempting to relate this to one of my pet gripes about software consultancy: we often seem to be engaged too late in the project to make the level of changes we are capable of. Specifically, I'm referring to a shortsighted and/or ignorant choice of development tools made well in advance of the formation of the development team, often with little/no practical knowledge of how these tools will impact the development process.

Before I continue, I should state for the record that I have no desire to mention any products by name. Nor is this a sideways swipe at OSS, although the "costs nothing" statement might have you thinking in that direction. Truth be known, the inspiration for this article comes from exposure to several high profile (and typically high cost) products, the combination of which has placed more obstacles to productive software development than any number of Mythical Man Month scenarios you might care to document.

The "choice" of these tools came about via corporate decree (i.e., existing licence agreements) and the "would you like fries with that?" approach of large product companies throwing in free copies of ToolMaster 3000 with every kids' meal. The practical upshot has been a development effort that is producing code at least 50% slower than it should, IMHO.

And in a lot of environments, these tool choices (e.g., version control system, IDE, application server) are effectively defaulted from what has been used in the past, with the development team having to accept the incumbent toolset with little option but to make do the best they can. And although tool choice is almost never (solely) responsible for a projects' demise, it can certainly make a large impact on the speed with which a development team can work.

So when the development team turns up for Day 1 of the development part of the project - lo and behold - most of the factors over which their experience should certainly have been used as the final decision criteria (e.g., toolset, along with team composition, architecture, etc) have well and truly been bedded down. Perhaps it's these sort of situations that led to Weinberg's Ten Percent Promise theory in his text, The Secrets of Consulting, whereby you should never promise to provide more than a 10% improvement to the situation you're addressing?

As a proud consultant who is a little miffed of seeing so many opportunities for improvement wasted because of decisions made prior to my arrival on the project... Grrrrrr!