In Peril from contractors

Blog Post created by Yorkshireman on Oct 16, 2015

I should know, I used to be one.


I've managed them, I joined the fray as one, and now I have to deal with the chaos that comes from letting contractors run free.


Let's be fair though.  A contractor is (or should be) a skilled professional, with in depth knowledge of the tools you are using, and brings to the table a wider experience of other installations and operating procedures than you can possible afford internally.  With a good brief, a specification of what inputs must result ion what outputs, and some standards and quality gates, a contractor will be efficient at cutting code, produce better code, and you may learn some new and 'better' ways of doing stuff that you never thought of.

Why else would you pay the rates?  When they work for a supplier they are called 'consultants' and cost vastly more per hour, and rightly so.


The perilous contractor though...  became a contractor because it would be easy money, with little responsibility, and their aim is to recycle their modest skillset as much as possible, invest no more time in expanding their knowledge base than necessary, and move on before the short cuts they took are found out.


And why do I write this now?


Well, I've just run across the output from a 'type B'  - a modestly capable RPG coder.  The sort of person that need(ed) plenty of input to guide them, or a quality specification that allowed no room for making up stuff as you go along.

Sadly, he or she was allowed to just 'do stuff' sans oversight, and as is usual, all is well until much later, when maintenance requirements kick in, and what should have been a simple job to attend to is found to be overly complex because standards weren't followed, and the QA in those days wasn't rigorous enough to look at database design issues -before- implementation.


Does it matter?

well, yes, and no.  he/she is long gone, the functionality is stable enough that an extra half day on a 15 minute task is still goodish value.


The real lesson is to learn from history.


In an age of agile development, even in our 2e tooling, we work in an ever more exacting ecosystem of components and relationships.  Sitting down and thinking through future potentials is rarely time wasted.  Its far cheaper than coding, and its time that pays back the very first time you have changes to make.  

Good design for our underlying database remains good design.

Good design makes future changes easier, cheaper, less risky, accurate.

Good design allows new functionality to access data in an efficient and timely manner.        

Good design takes the peril out of our future journeys.


Think on't