Wednesday, March 25, 2009

Even Superman had his Krypnonite

In Superman III, with Christopher Reeve, the Man of Steel is infected with a near perfect copy of material from his home planet, Krypton. What is important is that it is a 'near perfect' copy, not an exact copy, or even an actual piece of kryptonite. Rather than rendering Superman weak and useless it just makes him mean, and in the pivotal scene the nasty Superman must confront and vanquish the inner demons of his alter ego. Not only is the acting weak, but the special effects (particularly when Superman has to choke Supermean) are downright bad.

The only redeeming elements of the movie are when Richard Pryor, playing the part of a computer genius, gets filthy rich by skimming portions of pennies off company transactions (BTW - this actually doesn't work).

I too wrestle with inner demons as the architecture purest in me knows how to design and build reliable, flexible, high performing systems. Alas, I work in a profit seeking concern dedicate to fickle customers, subject to regulations, and (this stinks) budgets. Supermeanie in this case is me when confronted with the realities of time-to-market, project plans, vendor-specific solutions, and (this stinks) budgets. Any architecture can be found to be acceptable given the right amount of corporate coercion. Given some of the solutions I've seen (heck - approved) coercion is rampant.

It is with disdain for my own self worth that I routinely consider the skills of a team, their time constraints, and (this stinks) available budget and accept (but not embrace) a less-than-elegant design. We are, as they say, not an I.T. shop cleverly disguised as a business; we are a non-technology business dedicated to balancing the service needs of our customers within the costs of building and maintaining computer systems. If we produced heart-lung machines, aircraft control avionics, nuclear fuel pumps, we would have a different quality mission. I'm not suggesting that anyone allows low quality product out the door, but truth be told - nobody dies when our cost per line of code falls below $1,000. Lot's of people notice when the cost per line of code goes too high. Acceptable quality is a function of cost. We tightly control cost - more later.

But every now and then, I draw a line and just say no. This is particularly easy when I am not actually on the hook for anything. When asked to pontificate on the elegance of a design, I occasionally get to proclaim, "it's not best practice." Even rarer still, I get to observe that the reasons for an application issue are related to the nuanced loose correlation between some design element and an unexpected behavior. "I'm not surprised that your JavaScript is rendering the wrong calendar, as I see your database does not correctly apply the forth normal form."

If there is one element of quality that intrudes into my sanity engine more than others it is the presence (or absence) of a true (or even artificial) QA environment. I've stopped counting. I've stopped twitching, nervous ticking, blemishing, and/or expressing any kind of mock surprise when presented with yet another application that cannot be fully tested because "we don't have a QA environment." Rest assured, I know the reason why. Budget. It's not time, it's not knowledge, or passion, or technology, or even Dilbertized, pointy haired, brain dead, empty suit managers. Nope. It's budget. I get it.

A pretty sharp manager brought to my attention the other day the architecture of an application they recently inherited. The application is multi-tiered with components on file servers, two separate components on the host, and a database. In the test environment they had all of the necessary components in the server tier, and one of the two host-based components. For the other host component, they had to call a module in the QA space. Did you follow that - two host-based components, one (a) is in test, the other (b) is in QA. There is not (b) equivalent in test and no (a) in QA. Well, that's not entirely true. There is an (a) in QA, but the 'system' will automatically promote any (a) component in QA to production. So you can't really use QA to validate an (a) component as it will automatically go to production.

Anyone with more than ten years experience has probably seen, if not worked on, solutions like this. We all have our stories. I get it. This 'solution' probably got the team out of a jam at one point, and was even considered clever. Been there. But let's be clear. The QA environment should be an exact copy of production. The QA space must, must, must be a place where one can not only test the complete application end-to-end, but also illustrate, predict, and validate performance, error handling, functionality, and costs. QA is also a space to perfect the deployment process as how one deploys code to production should be the exact #$@#!! way it is deployed to QA. Right?!!

So henceforth and forevermore, I will not accept (I can be overruled) any application architecture that does not include a complete and proper QA environment. Now if someone wants to debate what is meant by complete and proper, count me in. At least that conversation won't give me hives.

Follow by Email