I’ve been hiring and working with programmers since 2001. Whether building a custom app or a website, certain principles must be recognized and adhered to or the results will be problematic at best, and needlessly expensive at worst.

Here are the top five things you need to consider when hiring a programmer in these situations.

All Requirements In Writing

Before you hire anyone, make sure you’ve got your requirements organized in a document that can be sent as a PDF to the developer. If you cannot write down what you need, then that means you must pay for consulting time with the programmer to get the requirements defined first. If you leave it up to the programmer to create the requirements document, you will need to make sure that you understand the document completely. It’s your website. You need to understand without a doubt everything that is going to be involved. If something is too technical for you to understand, make the effort to overcome that knowledge gap. It is imperative that this document be as perfect as possible before code is written. The consequences of not understanding everything you are paying for is simple: scope creep, cost overruns, broken deadlines. It’s not just a possibility, it’s assured. The requirements document (sometimes called a Request For Proposal, or RFP) is a foundational document.

Weekly Meetings No Matter What

Every week there should be a progress meeting with the developer. E-mails don’t cut it. Your developer should be open to meeting every week and reporting progress, challenges, and other aspects. Developers are not missiles; this isn’t “fire and forget”. You cannot turn over a requirements document and then expect the programmer to take it from there without weekly status checks. These meeting should take place by phone and/or screen sharing and should use the Requirements Document as a guide for progress.

I promise you new stuff will come up in these meetings that will require phone time. As a programmer works on a set of requirements, they experience something I call “peeling the onion.” This happens with graphic designers too. The principle at work is that “we don’t know what we don’t know.” As this is overcome, new ideas or requirements become known to the programmer that they will need to discuss directly with you. I’ve never seen a programming engagement that didn’t experience this. Plan for it, and you’ll be fine. Ignore it, and your project velocity will slow to a crawl.

Frequent And Continuous Testing

Gone are the days when a programmer can toss their work over to the Quality Assurance team to spot and fix programming errors. Programmers are expected to test their code as they write it. There is a concept called “refactoring” in programming (Knuth), in which the first draft of working code is not to be the last. As the onion is peeled and more becomes known about how to address a given requirement, the code should be improved to be more efficient, modular, and readable by other programmers. There’s more, but this is the rough idea of refactoring. Such code improvements come at a cost because quality takes time. Programmers that don’t know what refactoring is are to be avoided. Programmers that think it’s too expensive are to be avoided. It costs more up front but the ROI on the back end is considerable. It dramatically reduces the cost of code maintenance, troubleshooting, and enhancement. Refactoring always reduces the cost of ownership. Always.

Don’t Pay Until Milestone Reached

You might need to put down a deposit on a project. That’s fine and standard in the industry. However, when a milestone is turned in by the programmer, you are likely to get an invoice matching that milestone. This is where understanding the requirements document becomes critical. If you don’t understand the requirements deeply enough, you won’t understand what the programmer just accomplished and is billing you for. There should be two rules at work at this point: 1) The programmer should know up front that he won’t get paid until milestones are reviewed and approved; 2) You have promised timely review of all turned in work, and then the weekly review meeting will go over your feedback. By “timely” I mean next day or day after that at the very latest. If you cannot commit to that before the project starts, don’t start the project. Lag time on feedback is a huge impediment to keeping a programmer engaged. They often have many clients they are working with. If you delay on feedback, you are essentially delaying payment. It can take several days for a programmer to return to your project if you’ve taken 3 or more days to return quality feedback to them.

Documentation

My favorite! Nothing gets my techie juices flowing like a good technical document. But that’s because I know such documents are the lifeblood of a sustainable system. The programmer should document what they did such that another programmer could pick up the task if needed. If you are dealing with freelancers, this becomes even more important. Few things are more daunting to a programmer than to get in and understand another programmer’s work. Freelancers are notorious for disappearing after a project. Maybe they took a day job, maybe they got hired on a huge project, either way your project is in their rear view mirror and fading fast. They have no obligation to you after the final payment and the project is turned in. If something goes wrong with their code, they are under no obligation to respond at all.

Technical documentation is likely to be over the head of most of us that hire a programmer. However, it should still be created and paid for because it is that important to the longevity of the system.

Keep these aspects in mind and you will avoid most of what drives people crazy when they hire a programmer. You’ll minimize scope creep and cost, while increasing project velocity and accuracy. All good things!