19.09.2015 Views

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!