Sometimes it's not about the technology

In a recent conversation, I was asked about tool support for enforcing application architecture. The original team for this project had been increased from under 5 to more than 20, and many of the newcomers failed to grasp the overall architecture, choosing instead to forge their own way ahead for each new functional component. A reflection of this was the copy-paste coding, duplicating blocks of functionality with minor variations throughout the code base. What had started as a an application rewrite aimed at creating a model for future application projects throughout the department was quickly turning into a very sloppy project.

The question I was asked is a common, but unfortunate one. Things have been lean in many IT departments for a long time, even before the current economic downturn. I can't remember the last time I met a development team that was using anything other than cost-free tools and it's becoming very rare to meet any development team that has more than a skeleton crew as so much work has been sent offshore in the name of cost cutting. This is not to complain about either of those factors, but rather to recognize the state of affairs; this is reality, and it isn't going to change. The real frustration is the lack of skilled managers who recognize the difference between management and technology problems, which is directly correlated with the emphasis on cost over quality.

In the particular case I mentioned, it is impractical to try to enforce architecture through technology and even if it were, a poor excuse for good management. Don't misunderstand - the right architecture is addicting and leads developers to want to follow the pattern, so can act as a natural enforcer. My argument is that expecting technology to separate the wheat from the chaff when it comes to talent or productivity is asking for trouble and letting managers act irresponsibly. If a team has "renegade" developers who are creating sloppy, unmaintainable code outside the constraints of a selected architecture, then that's a reflection on ineffective technical management as much as a reflection on those developers. A tool might tell you who broke the build or how many times the same code block has been copied and pasted, but it is the responsibility of technical managers to notice problems, quantify, respond, guide, and otherwise act as stewards. The root cause is that due an endemic lack of training, rampant age discrimination, short sighted yet ineffective cost cutting, and the outright gutting of departments, the IT managers of today are grossly ill-equipped to both understand and handle these problems.

Here's another story. I once worked for a company with a publicly stated policy of never hiring consultants or contractors of any kind in its IT division. The history behind this was that many years before, a large well-known technology consultancy had come in and spent several years and several million dollars evaluating the technology operations. The final deliverable was two binders worth of "best practices." Needless to say, the CIO of the time was less than pleased with the way his money had been spent. The irony of course is that he should have been pointing the finger at himself, not the consultants.

The problem itself in this case wasn't with the vendor, or the technology and methodology being recommended, but with the way the project was mismanaged by that CIO. Anyone who has been in this industry for even a few years has dozens of these stories to tell and a pattern becomes clear. It really doesn't matter what tools you are using or how modern your methodologies. The differentiating factor between successfully delivering working technology solutions and utter disasters boils down to one thing: people. If your managers are simply filling out a space on the organizational chart and not actually being effective, or even worse expecting software itself to act as panacea for personnel matters, then you've got problems regardless of how SOA, Agile, and Cloud you may wish things to be.