Procuring software engineering services from a proven contract house has many benefits, which you already know if you’ve ever been cornered by one of their sales team members. As an engineer I know that there are always tradeoffs which must be made, and getting outside help on a project is no different. One possible way to maximize the value and effectiveness of contract software engineers is by the use of pair programming. Pair programming is an Agile software concept I was introduced to during my time working with a client, however it can be shoehorned easily into any development process. Pair programming simply means getting two engineers to sit together at the same workstation, often with two keyboards, to work together on a software solution. There are well documented benefits of increasing speed and learning while reducing mistakes and costs. In my experience, those benefits are compounded when using the services of a software contractor.
There is often a sacrifice of control made when using contract work. We’re often working remotely, and although we do our best to keep the lines of communication open, on-site workers may not be in the same habit, as they can always lean over a cubicle wall. Paired programming provides a degree of self-management as the pair does a very good job, in my experience, of managing each other in a healthy and constructive “lab partner” kind of way.
Another big hurdle for contract engineers is conquering the initial learning curve of the proprietary software and system knowledge necessary to provide good value to a customer over the course of a contract. This is where pair programming has a lot of potential for contract engineers. Often times if a client has used a contractor in the past or is using one right now, there is a perfect source to pass along that gained proprietary and system knowledge sitting in the same office! This can really cut the learning curve and can provide a backup of that experience which hedges against the classic problem of getting outside help: the gained experience leaves when the contract expires. Also an experienced pair can be separated later to mentor new partners creating a way for additional talent to provide immediate value for maximum flexibility.
Two nice benefits is about all I’ll fit into a blog-sized article on pair programming but for the company interested in the technique, there are many good resources out there. Perhaps the biggest hurdle to introducing pair programming is actually finding a window of time for it. Many of the client employees I’ve worked with have their days dissected into awkward chunks due to meetings and other obligations, that often don’t apply to engineers working on contract. This could make a contractor an attractive option to experiment with pair programming.
