Reach Customers Online

How To Evaluate Programmers, Without Being A Programmer

Updates to this article are noted at the bottom of this page.

You are a business person. You know customers, products, competitors, pricing, and how to make them make money. You do not have time to learn software programming. It takes years to learn, for one thing. But you do need to hire someone who can build a software application. Where do you start? How do you evaluate a skill set that appears to be very different from your business skills?

First, you do not have to know how to code software to get good results from a programmer. Picking the right person does not have to be a case of throwing a dart against the wall. Good results happen when you define your project goals clearly, you evaluate a programmer effectively, and you make sure the programmer follows basic programming guidelines.

A good software application does more than run with few errors. Most importantly, good software is built in a way that makes it easy for other programmers to maintain over time. An average business person can make sure both criteria are met.

What Is Your Project About?

The first step in hiring a programmer is to ask yourself, “What do I want to accomplish?” You might think the answer is, “Track leads from my website.” The best answer, however, goes far deeper. What do you want from your application, now and in the future? Focus on what kinds of detail you will need to make business decisions. It might be important to organize your data by postal code, for example, but not by street address. Or it might be important to organize your prospects one way and customers another way. Or you might need to access and use data from a source outside your company.

These subtleties become very important when your programmer builds your application. Software development is a mature industry and there are many examples of almost every kind of application. Which to choose, and whether to build your own, will depend on subtleties like how to describe your customers and what data tells you that your business process is working or failing.

Buy or Build?

The question of whether to buy software or build from scratch is not easy to resolve. Building software introduces significant risk that something will go wrong and will always leave you 3-12 months behind the functionality of comparable products. Buying software, however, often turns you into Goldilocks with too little or too much functionality when all you want is just enough functionality.

If your needs are small, buying software is probably the best way to go. In all other cases, the best way to proceed is to work with your programmer to clearly define your needs now and in the future then evaluate what software is available. You may discover having functionality that is behind 3-12 months is no big deal and that there is no software available that provides important functionality you need.

However, do not assume that building from scratch is best in all cases. Think carefully before you choose to buy or build. Your time and money are scarce resources. And beware of programmers who always build because the process of building software from scratch is so challenging and exciting.

How To Evaluate Programmers?

Evaluating and hiring programmers is more complex than reading resumes with an eye to long assignments, brand name employers, top schools, and certifications. These details are important. However, it is far more important for you to evaluate based upon a number of less obvious details that will impact the success (or failure) of your project.

There are at least three types of software programming skills you will encounter when you interview programmers. You will find programmers often specialize in one with modest, little, or no expertise in the others. Here are basic descriptions of these skills:

• Application programmers concern themselves primarily with the actual software code and how to make the code flexible today and tomorrow.
• Systems architects focus on the high level goals of the application which often includes hardware, interactions with other systems, and other worries. They also try to build systems that are flexible over time.
• Database designers worry about how data is organized within the data tables in one or more databases. Their goal is to ensure that data is returned as quickly as possible and is easy to maintain.

Which skill should you hire? If your application is fairly simple, an application programmer with database design skills probably will do. If your application will use or process large amounts of data, then a database designer is in order. You probably will want to hire someone with systems architecture skills for medium to large scale applications.

Besides understanding how programming skills differ, you should do due diligence. Ask the programmer for references, not only the clients who will sing their praises but clients who have had business problems similar to your situation. When you talk to references, be sure to ask about the scope of the project completed, how the programmer handled problems, whether or not the programmer is detail oriented, and how open the programmer was to questions from business people. For example, did they bark answers? Or did they take time to carefully explain key concepts so that everyone involved could make good decisions?

You also should ask references how much preparation work the programmer did before they started coding. This can include creating documents that list requirements, functionality, and test scenarios. But it might, and perhaps should, include notes from meeting the users of the application the programmer built. The last thing you want is a programmer who makes up requirements as they go. Or a programmer who builds based only on what a client says in a meeting. Documents allow all participants to confirm or deny critical details.

Another area to explore with programmers is their personal fit with you. If you are a high strung personality, make sure the programmer can handle that fact. If you are a quiet soul, make sure the programmer has the ability to pursue you to get the information and details they need to create great software. You also want to make sure the programmer is honest and upfront about the inevitable mistakes and setbacks that happen in software development. While references can help you decide about these issues, you must evaluate a programmer for yourself.

Finally, be sure that the programmer you choose feels comfortable with documentation. Research shows that there are many fewer errors and much less cost involved when software development is carefully defined, designed, planned, and implemented. One key factor to hidden costs are requirements changes in the middle of a project. Programmers are more likely to produce reliable code if they spend time up front to work with you and the users of your application to write up detailed requirements and functionality descriptions. That said, too much of a good thing can delay projects endlessly. Be sure to have enough detail but not so much that you choke your process.

Documentation also should include prioritization of requirements. You need to meld a list of requirements you want with the technology impact of those requirements. A skilled programmer will be able to tell you which requirements require more time to develop than others. You should structure your software project so that you can deliver functionality every 60-90 days with the simplest functionality first and more complex functionality in later phases.

The ability of your programmer to be comfortable with documentation helps in another critical way. The software should not only do what you want today. It should do what you need tomorrow. If the programmer is careful and thorough in collecting requirements, they will build a system that works now and in the future. Also be sure to ask your programmer to include in their price documentation of the application they have built, for example, at least a list of functions used with their inputs/outputs and what files the functions reside in. (Don’t worry, functions are described below.)

Basic Programming Guidelines To Follow

While a business person does not have to know software programming to get good results from programmers, it helps if you know a few software basics. This will allow you to evaluate the overall quality of your programmer and make sure that the application they build will be easier to maintain over time.

Don’t freak, however. These software basics are relatively easy to learn. They also will help you understand what you are asking of the programmer.

Good programmers build applications that include a file that contains all the configuration variables and common functionality used throughout the system. Why is this important? Imagine that your software sends email to your twenty sales offices. What happens when you add a new office? Or change the address at five of your offices? A central configuration file allows your programmer to update a single file. It does not take much effort to use configuration files and will save you lots of effort later.

Another hallmark of good software programming is the use of variables. Think of variables as place holder names. Instead of referring to a database table by its actual name, for example, you refer to it with a variable. This allows your programmer to change the database table name once, by redefining the variable (usually in the configuration file) rather than in the dozen or more places in the code where that database table is referenced.

The use of functions also makes maintenance of your application easier. Functions are self-contained bits of code that work like little engines. You might have an email function, for example, that is used by all parts of your application that send email. Another function might insert data into your databases. As with variables and configuration files, functions allow you to maintain one set of code that is used throughout the application. Changes to the email function, for example, can be made once instead of every place in your code that send email.

Database “normalization” is another important skill. The goal of normalization is to ensure that data (for example, a customer address) resides in as few places as possible within the database. Why? There is less complexity and less risk of failure if data changes can be made in one location instead of many.

Imagine this scenario. Your biggest supplier has one address today but adds two more locations next year. Then their company is bought and their name changes. This could cause a huge maintenance nightmare.

In a normalized database, vendor names would be in a table separate from addresses. Let’s say the database table is called tblVendorNames. In this table, you might have two columns, VendorID and VendorName. Another table, let’s call it tblVendorAddresses, contains at least two columns of data, VendorID and VendorAddress. This arrangement allows you to add (or delete) as many addresses as you want without impacting the vendor name. It also means that when you change the vendor name, in the tblVendorNames table, the change will apply to all the address records. Why? Because they reference the unique id used to identify your vendor, the VendorID value.

Now imagine if you did not do normalization. Let’s say you put the vendor name next to every instance of an address. When your vendor changes their company name, you have to update multiple locations in the database, not the one location in my example. As noted above, the primary goal of programming is efficiency and simplicity. That drives down the error rate and makes code easier to maintain.

Finally, good programmers use consistent syntax when they code applications. This enables them, and programmers who might maintain their code in the future, to read and understand their code long after they have forgotten what they did. Syntax includes comments that explain what functions do and grouping variables. For example, you might have five different types of status and it is important the status variables are grouped together in the configuration file rather than spread around the file. Syntax also includes indenting code so that it is easy to see how pieces of code relate to each other. And it is important your programmer label variables consistently. For example, integers (numbers to lay people) might be prefaced by “i” (as in iVariable) so that the programmer knows the variable is an integer and will respond certain ways. Or database tables might be prefaced with “tbl” (as in tblTableName).

That wasn’t hard, at least not until integers were mentioned. In addition to checking references and other criteria, be sure your programmer works in ways that make it easy to maintain their code. Good programmers will not mind your questions. In fact, often they will take the time to educate you about other equally important issues. If you interview a programmer and they dismiss or ignore your questions about how they code, be sure to thank them for their time before you let them go.

Which language to use?

The last issue to discuss about hiring a software programmer is what programming language to use and, in some cases, what database.

Choice of language and database hinges mostly on what software applications you currently use. If you have alot of Microsoft software, seriously consider having your programmer work with Microsoft languages and databases. The less technology complexity you have throughout your business, the better off you will be over time. It is a needless nightmare to maintain applications written in two or more different programming languages.

Another factor to consider is availability of programmers with a particular language skill. Some languages are less common than others and maintaining code in that language could cost more because there are fewer programmers with that skill. Languages such as Perl, PHP, and Classic ASP have very large numbers of programmers. Languages such as .Net, Java (JSP), and Cold Fusion appear (to me, at least) to be slightly less common. In the database realm, Microsoft SQL and MySQL are very commonly used databases. Other databases also have strong communities.

The quality of the programmer in front of you, however, always trumps what programming language you choose. Any of these languages or databases are common enough to be supported well for the indefinite future.

Therefore, be absolutely sure you know what you want them to build for you. Then follow the criteria above as you evaluate programmers. Chances are high that the combination of questions, references, resume, and personal interview will make it clear that one programmer is better suited to your needs than another. Best of all, you did not have to learn programming to evaluate them.

Changes To This Article

August 10, 2004: Added Resources section with a link to Great Hacker != Great Hire article. Cleaned up the paragraph on normalization.

Resources

Great Hacker != Great Hire
If you don’t know, != is programming shorthand for “not equal.” This is an excellent article that describes the fussy programmer type perfectly, the kind that will bark at you if you ask a dumb question, the kind you probably don’t want to hire if you’re a small business.

Related Stories

Quickly Editing An XML File With .NET

Writing Quality Software: A Primer

How to be a Software Program Manager

Rent A Coder: An Alternative Way to Get Software Programming Done

Road Test: Four Databases Tested

How to evaluate a content management system

Low Cost Online Databases