Forums
Sep 06I Think I'll Call Them "Transactions"
by in Feature Articles on 2006-10-31As programmers, we derive satisfaction from our ability to create solutions to other peoples' problems. Unfortunately, the problems that we solve aren't the exciting "world-hunger" type, they're more along the lines of, "Sally is spending too much time doing expense reports and would like to automate the process." The inherently boring nature of these business problems lead many programmers to seek out new problems to solve, the most common of which is the meta-problem: a problem with the process of creating a solution for the actual problem.
The solutions to meta-problem take on many forms: NIH (Not Invented Here), IHBLRIA* (Invented Here, But Let's Reinvent It Anyway), The Inner-Platform Effect*, and so many others. Every once in a very rare while (as of yesterday, only seventeen times in the history of all software development), the existing development tools are not adequate in solving the immediate problem and the solution to the meta-problem is actually beneficial to the overall solution. Today's example, courtesy of Robert Rossney, is not one of the seventeen.
The year was 2002 and the technology boom had officially come to an end. As a graduate fresh out of college, JF didn't even have a fighting chance. Practically everyone in I.T. was out of work and was willing to take just about any job to pay the bills: senior-level developers were lining up in droves for junior-level positions; juniors were going after all the entry-level jobs; and the entry-level folks like J.F. were struggling to find any type of job that had any resemblance to technology.
One of the advantages to working at a large organization is that they're very serious about the integrity of their "mission-critical" systems. By the time a code change makes it through the Development, Integration, Testing, Quality Assurance, and Staging environments, it's practically guaranteed to be bug-free. And if a defect does manage to sneak in to Production, no single person can be blamed: it's the fault of The Process for allowing the problem to occur.
I'm always amazed at how similar things were back in the 70's. Some companies even offered "performance enhancement" upgrades as they might today. Mark recalls all that was required to nearly double the performance of the IBM 407 Accounting Machine: a sum of money, a technician visit, and a single wire being snipped from the control panel. 
J.T. is not well liked amongst the developers at his organization. As a Database Administrator, it's J.T's job to make sure that database structures and queries maintain data integrity and do not put an unnecessarily load on the server. This often gets in the way of the developers, who prefer to think of the database as a giant dump site where data gets thrown and is rummaged through to be retrieved. Things like "indexes," "valid data," and "naming conventions" are merely obstacles put in place by J.T. to make their life harder. 
Cascading Style Sheets are an excellent tool used by web developers to put the repetitive formatting details -- font Tahoma, color Mauve, weight Bold, etc -- in a single, easy to maintain place. Of course, no developer actually expects to work on a site that utilizes them. But still, it's comforting to think that maybe, one day, one of us just might be lucky enough to come across that one client who actually uses them somewhat properly. 
In an ideal world, a track record of such incompetence and failure would lead to a swift and harsh de-hiring. But in Paul's world, his team was usually in The Wrong and the Certain Developer was always in The Right. After all, the Certain Developer followed the software development methodology pioneered by The Executive Three (President, VP, CTO): if the MAKE process works, then deploy the build to the customer site; if the customer notices any problems, deploy the previous build to their site.