Confessions of an IT Manager_Phil Factor
- No tags were found...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Section III: S<strong>of</strong>tware Projects: the Good, the Bad <strong>an</strong>d the Pitiful 105<br />
It may not be logic that fires the hunger for the latest technology. One <strong>of</strong> the<br />
str<strong>an</strong>ge side effects <strong>of</strong> testosterone is <strong>an</strong> irresistible urge to play with the latest<br />
technology, <strong>an</strong>d it is hard to distinguish real productivity from unashamed selfstimulation.<br />
It takes courage <strong>an</strong>d willpower to adopt a relatively conservative approach<br />
to development work <strong>an</strong>d select the technology appropriate for the application.<br />
When I pl<strong>an</strong> a project, I generally construct a 'playpen' area in which all the<br />
latest technologies are used to develop a non-critical project component, <strong>an</strong>d<br />
then let each team take turns developing it.<br />
The team gets to put all sorts <strong>of</strong> skills <strong>an</strong>d technologies on their CVs, <strong>an</strong>d<br />
the pressure is <strong>of</strong>f to prematurely adopt a f<strong>an</strong>cy technology for the project's<br />
serious deliverables. We c<strong>an</strong> then inform the project sponsor that we are using<br />
glitzy technology just like in the advertisements, <strong>an</strong>d everyone is happy.<br />
Code, then recode<br />
Throwing away code, just when you've gotten it to work, may seem unkind<br />
or unnecessary but is actually a deeply cle<strong>an</strong>sing experience, like sloughing <strong>of</strong>f<br />
dead skin. I discovered this by accident when the bad luck fairy struck <strong>an</strong>d no<br />
one had made backups.<br />
Initial feelings <strong>of</strong> despair were followed by a curious lightness <strong>of</strong> spirit, as<br />
all the false turnings <strong>an</strong>d cul-de-sacs <strong>of</strong> everyday coding were forgotten. We<br />
knew what needed to be built, having done it once, stumbling in the half-light<br />
<strong>of</strong> the systems <strong>an</strong>alysis.<br />
When we keyed it all in again, it was half its previous length <strong>an</strong>d r<strong>an</strong> twice<br />
as fast. It didn't take long to do it either, <strong>an</strong>d we hummed as we worked. I've<br />
since discovered that the same applies to <strong>an</strong>y creative work. Tentative work<br />
should always go on the fire.<br />
Discourage virtuosity<br />
The principle that you should never let a programmer do <strong>an</strong>ything you<br />
c<strong>an</strong>not underst<strong>an</strong>d is a classic one, first articulated by C.A.R. Hoare, inventor <strong>of</strong><br />
the Quicksort algorithm. It is ignored at your peril.<br />
My worst experience with this behavior was when I was supervising a<br />
freel<strong>an</strong>ce Sybase programmer who created a reporting system for a fin<strong>an</strong>cial<br />
services comp<strong>an</strong>y. He used dynamically compiled stored procedures that were<br />
created in response to the exact slice-<strong>an</strong>d-dice query required by the fin<strong>an</strong>cial<br />
<strong>an</strong>alyst.<br />
He almost got the code working to the satisfaction <strong>of</strong> the business, <strong>an</strong>d then<br />
dem<strong>an</strong>ded a doubling <strong>of</strong> his contract rate. We parted on bad terms, <strong>an</strong>d I was