What do we assume when we contract people to write software for us?
Many of you have been there. You need something done, you find someone, they give you a quote for the work, you agree, they do stuff then send it to you. It's just not really good enough. It's probably not terrible (but it might be) it's probably OK but there are enough things wrong with it that you can't just shake hands and pay them their money.
On the other hand, they have put in the hours, so it's probably not right just to not pay them anything but if you are going to have to mostly rewrite it - which defeats the point of getting the work done - what can you do short of legal action?
One of the most obvious things that we don't always do is write a good contract/requirements. Like a good Job Description, if you write it well, it should simply be a case of "is the person doing this?" if so, great, if not, they don't get paid.
Let us take an example. We want someone to write a plugin for Magento that handles an OAuth2 handshake for a web site. Sounds simple and it sounds like something that a Contractor would say, yeah, OK, I'll do that! But there are many things missing from such a simple requirement. One of those might be a simple question: "Have you ever written a Magento plugin before?" Why? Because although the PHP might be easy, the architecture and philosophy of Magento is not something you can simply learn from a book in a few days and I certainly don't want to pay a Contractor to watch videos and try and learn it. What if they produce something that seems to work but they did it really badly? You might not know until later.
Secondly, assuming that they have some experience that you are comfortable with, there is then a question of quality and speed. Most of the time, we are not contracting to crazy deadlines but there is still a large difference between fast and slow, especially when you are paying a day-rate of money and to make it worse, speed and quality are proportional so fast is not always good. How can you tell what their quality and speed are like before taking the plunge and committing to large amounts of money?
You can do two simple things up-front. Ask them to send you an example of some of their code from another project (or even something they have contributed to Github or whatever) does it read well? Does it look like a professional or someone who might have made something work by luck rather than skill! Secondly, set them a test - or rather the first part of the work. For example, in our example above, ask them for the basics of a plugin that doesn't do much (maybe does a browser redirect) using some hard-coded values, some basic UI - anything that should be quick and easy, the hard stuff is always in the details. You can pay them for that work if they have done OK up until now and then review what they've done and decide whether it is good and whether it matches the expectations they set. You should be honest with these people - if they don't convince you that they are producing good enough code in reasonable time, you are not going to continue to use them. Paying 2 days up-front for a project that might be 2 months long is good business! Best to lose a small amount early on and find someone else than to have to fix everything later.
Another important point is to document and communicate your expectations. If they need code to look neat, it needs to be said. Not all Developers care and if they don't know you need that, you can't complain to them when they don't deliver it. What about Unit Tests? Design sign-off? Acceptable libraries? Browser testing? If there is something complex that your project involves, can you separate that into another package and get them to prove they can do that? If not, let them do the easy stuff and pay someone else to do the hard bit.
Hopefully, you eventually find some good Contractors who you trust, whose code you know is quality, who are responsive to the work you are giving them and who are not charging crazy amounts of money in the process. This will be ongoing if your business is growing but so many of us have to use Contractors that it is a skill that your company needs to have.
On the other hand, they have put in the hours, so it's probably not right just to not pay them anything but if you are going to have to mostly rewrite it - which defeats the point of getting the work done - what can you do short of legal action?
One of the most obvious things that we don't always do is write a good contract/requirements. Like a good Job Description, if you write it well, it should simply be a case of "is the person doing this?" if so, great, if not, they don't get paid.
Let us take an example. We want someone to write a plugin for Magento that handles an OAuth2 handshake for a web site. Sounds simple and it sounds like something that a Contractor would say, yeah, OK, I'll do that! But there are many things missing from such a simple requirement. One of those might be a simple question: "Have you ever written a Magento plugin before?" Why? Because although the PHP might be easy, the architecture and philosophy of Magento is not something you can simply learn from a book in a few days and I certainly don't want to pay a Contractor to watch videos and try and learn it. What if they produce something that seems to work but they did it really badly? You might not know until later.
Secondly, assuming that they have some experience that you are comfortable with, there is then a question of quality and speed. Most of the time, we are not contracting to crazy deadlines but there is still a large difference between fast and slow, especially when you are paying a day-rate of money and to make it worse, speed and quality are proportional so fast is not always good. How can you tell what their quality and speed are like before taking the plunge and committing to large amounts of money?
You can do two simple things up-front. Ask them to send you an example of some of their code from another project (or even something they have contributed to Github or whatever) does it read well? Does it look like a professional or someone who might have made something work by luck rather than skill! Secondly, set them a test - or rather the first part of the work. For example, in our example above, ask them for the basics of a plugin that doesn't do much (maybe does a browser redirect) using some hard-coded values, some basic UI - anything that should be quick and easy, the hard stuff is always in the details. You can pay them for that work if they have done OK up until now and then review what they've done and decide whether it is good and whether it matches the expectations they set. You should be honest with these people - if they don't convince you that they are producing good enough code in reasonable time, you are not going to continue to use them. Paying 2 days up-front for a project that might be 2 months long is good business! Best to lose a small amount early on and find someone else than to have to fix everything later.
Another important point is to document and communicate your expectations. If they need code to look neat, it needs to be said. Not all Developers care and if they don't know you need that, you can't complain to them when they don't deliver it. What about Unit Tests? Design sign-off? Acceptable libraries? Browser testing? If there is something complex that your project involves, can you separate that into another package and get them to prove they can do that? If not, let them do the easy stuff and pay someone else to do the hard bit.
Hopefully, you eventually find some good Contractors who you trust, whose code you know is quality, who are responsive to the work you are giving them and who are not charging crazy amounts of money in the process. This will be ongoing if your business is growing but so many of us have to use Contractors that it is a skill that your company needs to have.