Contract working is often pot-luck and whilst it would be nice to be able to pick and choose gigs based upon whether they advance career, boost knowledge or remunerate well, the need to pay the rent can mean that any job is better than no job.
Sometimes a project needs many experienced hands quickly and the challenge is keeping up with many bright and motivated colleagues in a fast-paced environment. Other contract roles can mean delivering specialised knowledge to bridge a short-term knowledge gap. And then there are the assignments that require contract staff to plug a hole where morale is so low that quality staff have already decided that their careers and sanity require moving on as quickly as possible.
One of my favourite cum worst contract horror stories was a role working in an IT department that managed the records of over a million subscribers.
Monday and Tuesday of my first week were spent on introductions and setting up a workstation. Wednesday was spent being given an overview of the entire system. The system that had been developed over a number of years by a well-known outsourcing company yet there was not one single line of test code nor was there an automated build system. On Thursday I was given a run through on how the system was deployed; there was no automated deployment process. Most of the deployment process was a case of “type this into this box then click here, then move to this computer and type this into that box, then click there, wait for the icon to stop moving then go over to another computer, type this in.” And so it went on. The demonstrated process took a couple of hours and comprised a huge number of steps; the notes that I’d taken ran to several pages.
As well as there being no automated deployment, there was no staging environment either – everything went straight into the production system from the development environment – there was no opportunity to practice a deployment. Boiled down, the “process” comprised of developers putting their unproven code onto a live system and hoping that everything worked. If something went wrong then the rollback procedure was the follow the deployment process in reverse and then re-deploy the old code.
Having been shown a deployment dry run, then came the sucker punch: “so can you do the deployment tomorrow?”
Hold the guacamole
As a student I had once worked as a waiter in a low-rent American-themed restaurant where it took three weeks before a new starter was allowed to take orders from customers without supervision. Believing that I could assimilate the salient deployment features of a large legacy system in less time than it took for me to be able to recite the contents of a Tex-Mex diner menu was flattering but several stages removed from reality. It was symptomatic of the organisation’s hope that there existed in the outside world a panacea that would fix the department’s woes.
The moral: hiring contractors is not a silver bullet for addressing systemic problems.
I said no to doing the deployment, by the way.