It can be difficult to know how good a job your IT professional is doing. If you haven’t hired many people before, or you’re not a programmer, it can be even trickier.

Fear not: this is my quick guide to some of the most common problems I’ve seen and heard about. I’ll list exceptions to each rule, but if more than a few of these match against your current professional, you might like to reconsider continuing using them.

1. Slow replies, or emails / phone calls are ignored altogether.

This is by far the most common symptom of a failing project and of a deteriorating business relationship. It is emphatically not normal to have to wait days for a reply to a simple question, nor to have communications routinely ignored.

Exceptions

It’s always good to bear in mind that emergencies happen, whether it’s a broken internet connection or something less trivial.

You should also ensure that you and your professional are clear on what one another consider “late” to be: is your professional simply under the impression that replying 24 hours later is fine, when you’d prefer replies the same day?

2. Regularly delivering features that don’t work.

You’ve been told that a new feature is up and running, load up the website and *bam* nothing but NOTHING works. It’s almost as if your professional didn’t bother to test the new feature before putting it live!

Be assured: if your professional isn’t testing things for themselves before telling you to take a look, they’re probably not the professional for you. Doing so repeatedly is as big a warning sign as you’re likely to see.

Whilst some mistakes are inevitable – we’re all human – bugs can be kept to a minimum mitigated somewhat by using automated testing.

Exceptions

Your professional might state that a particular feature is in “alpha” or “beta” state, meaning that the code is for testing, and some bugs or issues are expected. Your developer will find it extremely helpful to have a second set of eyes go over a new feature.

Have you asked your professional to work outside of their ideal circumstances? Lots of professionals will refuse to work late at night, or if they’re unwell, as they know the quality of the work they deliver will suffer.

3. Unexplained problems.

This typically takes two forms: features that don’t work properly; and performance issues, such as a feature taking too long to do its thing.

Whilst it’s unlikely that your professional will immediately know why a feature doesn’t work or has poor performance, once given the opportunity to investigate, it’s unusual for the issue to remain completely unexplained.

In short: if your project has many unsolved and unknown issues, you may be in trouble.

Exceptions

Information is key, and your professional must have the opportunity to investigate what’s happening before you can expect an explanation.

4. Being lazy: no backups; no source control; and not tracking issues.

This is a BIG RED SHOUTY WARNING SIGN.

At the very least, your project and its content needs to have a backup stored somewhere. Your source code should be stored in a revision control system such as SVN or Git. And you should keep track of issues and feature requests in a dedicated tracking tool.

A failure to do any one of these is as close as can be to a guaranteed sign that your professional is not up to the job.

Exceptions

Unless you have refused to allow the setup work to take place, there are no exceptions.

5. Controversial: using the CakePHP framework.

BIG HUGE CAVEAT: there are plenty of highly competent PHP professionals that use the CakePHP framework.

However, if you already have doubts about your professional and they insist on using CakePHP, be warned: CakePHP is the most common factor amongst the broken projects we see.

Exceptions

There are many legitimate reasons to use CakePHP. Sadly, its attraction to the inexperienced and untalented is why it features on this list.

6. Getting database basics wrong.

Here are a couple of examples of professionals getting the absolute basics wrong.

1. Passwords stored in plain text. if you take a look at your database, find a table with “users” in its name, and has a column called “password,” can you see the password right there and then? This is a huge warning sign, and passwords should never be stored in human-readable form.

2. Tables should often have a unique ID column, and this column should be an integer, definitely not a string. This is true wherever you see the ID column being used. So if you have a user_id column, it should always be an integer.

3. You should not see SQL queries that begin: SELECT * FROM table_name

Exceptions

There are no exceptions for storing plain-text passwords.

ID types and “SELECT *” queries can be more complex, but should be the exception, not the rule.

7. PHP specific: using include() and require() inappropriately.

We see this time and time again in broken projects. Here’s an example:

/*
* Lots of code before this ...
*
* ... and now here in the middle of some random file:
*/

if ($something_happens)
{
    include('something_that_looks_like_a_filename.php');
}
else if ($something_else)
{
    include('a_different_file.php');
}

if ($different_thing_happens)
{
    require('yet_another_file.php');
}

It’s fine and expected to use include(), include_once(), require() and require_once() at the start of a code file, but after that, in the middle or elsewhere? No.

Exceptions

Very few and far between. If the code deals with displaying stuff, there may be a case to be answered. If the code is responsible for logic, however, be careful.

Conclusion

As you can see, there are exceptions to pretty much every rule I’ve listed here. It should also be kept in mind that everyone has a bad day from time to time.

That being said: if you think your professional falls foul of a few of these rules, and does so repeatedly, you should probably start looking elsewhere.

This article originally appeared on TBB Polska’s website