Tips for Hiring and Working With Programmers

If you’ve ever worked with a programmer, you know that some programmers are smart, funny, and can make your project successful. Other programmers can ruin a project, making everyone's life miserable in the process. Here’s my list of the top 5 programmers to avoid like they have contracted a scary disease.

Know-it-all Nancy
Nancy has no interest in your input. In fact, Nancy will roll her eyes at you when you offer an opinion. Nancy thinks all her programs would work perfectly if it weren’t for the users.

Jumpin’ Jack
Jack jumps in and makes changes without considering the implications. Unfortunately, this means that his fixes often break other things, or are ill-considered. Working with Jack means you’ll be spending as much time backing out of his "improvements" as implementing them.

Slow Joe
Slow Joe is the opposite of Jack. Joe can’t complete any fix or enhancement without at least a year of analysis and study. We don’t know why Joe is so slow, but finding out would probably take too long. We have lives!

Tongue-tied Ted
The reason why Ted became a programmer was because he thought he wouldn’t have to speak to people anymore. Unfortunately, Ted was wrong. Programmers need to communicate with end-users, project managers, business owners, and other programmers. And since Ted doesn’t like talking to people, he’s unlikely to ask the questions he needs to do a good job.

Hacker Harry
Hacker Harry likes the idea of having power over the company. He thinks privacy rules don’t apply to him. So, he likes to hack into the server to read everyone’s email. He guesses passwords to access systems that he doesn't rights to. Harry likes the power he has knowing more about technology than others, and isn’t afraid to use it for his personal benefit.

Just the other day I sent a proposal to one of my customers for ongoing support. I prefer to establish a flat-rate monthly support plan for my customers, which can be used for questions, troubleshooting, bug fixes, and emergencies. The flat rate arrangement is good for my customers, because they can budget for it appropriately. It is also nice for them, because they don't have to make an investment decision each time they call. ("Is this question worth getting charged?") I always prioritize my customers who have this kind of arrangement.

This post by Lynette Chandler at Small Business Branding covers why you need a plan for technical problems before they happen.

If you have never worked on a software development project before, you may be completely shocked during the first testing session. I guarantee that you will find a bug in the system within the first hour. In fact, you are likely to find something you didn't expect in the first 10 minutes.

This may trigger a panic attack in you. I know exactly what you are thinking: What happened? Didn't the programmer test at all? Did we hire the wrong person? We are doomed!

Calm down. Take a deep breath.

Let me give you some information about software bugs that will help you traverse this scary time. 

First, finding bugs is normal. In most software projects, a programmer (or team of programmers) write the code and do a lot of their own testing. However, fairly quickly in the process they develop blind spots. They start testing using the same steps, and they miss the steps that you used. That's why it is critical that someone who is not the programmer test the software.

Second, a good programmer HATES bugs. Despises them. And wants to kill them dead, er, fix them. Quickly.

Third, a programmer needs information to fix bugs. He needs to know what happened and what you expected to happen. He needs to know how to reproduce the problem so that it can be fixed. (Here are some tips for writing really good bug reports.)

If you have provided a good bug report, and the programmer reports that the bug is fixed but it isn't, now you can panic. Well, actually no, you don't need to panic unless this happens repeatedly.

Let me tell you a secret: While I hate bugs, I'm actually happy when my users report bugs during the testing phase of a project. When users find bugs during testing, that means we'll get them fixed before we go live. I have seen plenty of projects where the software was not sufficiently tested up-front, and went into production with lots of bugs. It is better to find those problems early and resolve them, than to subject lots of users to them later.

Even if you aren't paying for custom software on an hourly basis, you probably still care about how long it will take for the programmer to complete the work. After all, you hire a programmer because you think custom software will add to your bottom line, either by saving you money or increasing your marketshare. So every day without your new software is costing you cash.

Programmers are notorious for missing deadlines and taking longer than they promised. So if programmer says they will be done with your project by X date, how can you tell if they are just blowing smoke or if they really know?

Sync your terms. Sometimes the problem is really a question of interpretation. The programmer says "I'll be done on June 1st", and you think "Cool - we can start using it then!" But really, the programmer just meant the initial code would be done on that date, and wasn't referring to set-up, testing, deployment, or training - all additional tasks that must be completed. So, when you talk with the programmer about milestone dates and deadlines, make sure you are speaking the same language. Ask specifically about when you'll be able to use the software "live" or "in production".

Pay attention to the trees. Don't just focus on the "forest" or end goal. A good programmer knows that there are a lot of intermediary steps that occur in any software project. They should be able to provide you details and estimated completion dates for each step in the process. You want this for two reasons. First, there may be tasks for you or your staff to complete in this process, such as testing or entering products for an online catalog. You may learn that the programmer will be fine, but you'll need an additional week to complete your tasks. Second, uses this opportunity to probe further. You may not know anything about programming, but you probably have some sense of what is going to be complex. Ask questions about the details you have received to make sure you understand what to expect. A good programmer will welcome the opportunity to double check their understanding of the requirements with you.

Ask their references. When you talk to their references (you are checking them, right?) make sure to ask about how well they did with the deadlines. Some programmers aren't good at estimates, and others aren't experienced. 

Estimates are always tricky, and don't expect the developer you select to be perfect every time. But you can expect that they will work hard to meet the commitments they have made to you, and will let you know if they can't.  

If you are like me, you have seen your share of really bad web applications. You have probably wondered "How could anyone design something this crappy?"

I am going to tell you.

The secret to designing a really awful user interface is to think like a geek and not like an end-user.

That's it.

I'll give you an example you will see on many e-commerce sites. Many of these sites don't let you enter a credit card number with dashes or spaces. Believe me when I tell you that there is no good reason why sites do this, and it makes it much harder for users to enter the correct number because they can't easily break it down into managable chunks. (Here's the No Dashes or Spaces Hall of Shame, in case you are interested in seeing examples of several companies that do this.)

This is what comes of thinking like a programmer. The programmer went "hey, I need to send this to the payment processing company without those spaces or dashes, so it will be better if they just don't enter them. Or, they didn't want to write a bunch of complicated validation logic for each type of credit card number. Unfortunately, they just ended up with software that was harder to use.

Of course, getting into the head of your users isn't easy. But if you want really great software, you have to be able to think like they do.

When you talk to programmers, sometimes they will talk about methodologies. In fact, some programmers will go on and on and on about them. If you are hiring, they may tell you that they use “agile” practices or “waterfall”. As your eyes glaze over, you may correctly wonder “do I need to care?”

The answer is: No.

The question of methodologies can make a lot of programmers very religious. I’ve seen perfectly normal people get quite aggressive when they started talking about their chosen software development approach. Even the sales people for consulting firms can say quite pompously “We use only agile methodologies in our software development projects” as if they were talking about gold or something. Geez!

If you are not technical and are trying to select a programmer or team for your project, don’t worry about methodologies. Using a particular methodology is no guarantee of success.

Instead, focus on proven results. Ask to speak to their references. Hopefully these are organizations with projects that are similar to yours. IF you are building an online store that will need to service thousands of transactions a minute, then talk to a customer with a similar online store they built. Or if your project is a cool new iPhone app, then find out what kind of iPhone development experience they have.

If you want a successful software project, using programmers with proven track records will increase your chances.

Yeah, but Avonelle, what do all those methodologies mean?

Okay, just because you asked for it, here is some very basic info on software development methodologies:

There are lots and lots of “methodologies”, but they can be organized into two groups:

• Waterfall processes
• Iterative processes

With a waterfall approach, system development is very orderly. You start by defining requirements, then create a big design (usually a long document or set of documents), then write code, then test/fix the code, then deploy it. Done. Once you move to the next step, you don’t usually go back to a previous step. Sometimes people call this approach BDUF (big design up front).

With an interative approach, software is developed in several “iterations” of usually 2-4 weeks long. Each iteration includes planning, requirements, design, coding, testing, and deployment. With an iterative approach, it is thought that issues and misunderstandings about requirements can be more quickly identified and addressed than a traditional waterfall approach. (Some iterative approaches include agile and scrum.)

Again, I don’t think you need to worry about these things, but since you asked…

None of us wants to pay more than necessary for anything, including programming services. Sometimes the lowest bid is a great deal; sometimes it isn't. Here are some things to consider when comparing bids for software development:

Compare apples to apples. Make sure the bids you are comparing are all fixed bids, and not hourly rates (even with an accompanying estimate.) Because estimates are not typically binding, and every developer works at a different speed, hourly rates are a more way to compare bids.

What's included? Make sure you thoroughly understand what is included in each bid. Here are some things that might be extra in some bids and not in others:

• Hosting costs
• Status meetings/reports
• Third party development tools
• Source code backups
• Ongoing support/bug fixes

Making contact. Some programmers will be willing to work in your office or at least occasionally visit. Others may charge extra for this service, or may not provide it at all. And some will be able to guarantee response times for questions and changes, and some will not. As you approach deployment of your project, knowing that the programmer will prioritize your application issues may make a big difference if you are coordinating a public roll-out.

Make sure to ask lots of questions so that you can more completely compare the bids you receive for your project.

Ryan at 37signals recently posted on the dangers of adding new features to software. Once a new feature is added, it is difficult to remove even if it doesn't work well and not utilized by the majority of your users. The problem is that SOME users will likely become frustrated when the feature is removed.

Ryan suggests that this should inspire you to be very careful about the features you implement. I think this advice depends a lot on the size/impact of the feature, but his point is valid.

The problem is - what should be done if the feature IS clunky and difficult to support? The application we recently deployed is designed to replace a couple of existing applications and processes that had been in place for years. It has a better underlying data structure, and a more streamlined user interface. But it also removes some features, like automatic faxing of reports to subscribers.

Will users be comfortable switching to the new system? Only time will tell. It was a risky decision and the customer spent time evaluating the alternatives, but ultimately for my customer, the decision was about limited resources and how to best serve their community.

There are a lot of technology amateurs out there posing as experts. How can tell what a technology/programming poser looks like?

Gets excited about technology and ignores results. A true professional knows that technology is only a means to an end, not the end itself. But lots of posers get caught up in the "coolness factor". Unfortunately, many "cool" things will not improve your business. Posers don't understand this.

Undirected troubleshooting. I once worked with a consultant who would try to randomly change things when she ran into a technical problem. A poser doesn’t understand the technology he/she is working with, and therefore has to resort to troubleshooting techniques that are inefficient and often unproductive. Professionals are effective at finding resolutions to problems in a systematic and thoughtful manner, because they understand how the underlying technology works.

Gives up when faced with a challenge. Amateurs will often quickly give up when faced with a technical challenge. I've seen consultants spend 5 minutes on a problem, and then basically tell the customer to "live with it". A professional will work hard to find the answer, and if they fail they will at least find alternatives to consider.
Have you ever seen a software poser? How could you tell they weren’t a true professional?

This week one of my customers is rolling out a new system. The new system is a vast improvement over their current processes in the following ways:

• Information is not repeated. In previous versions, the same data existed in multiple places, making it difficult and time-consuming to keep consistent.
• Let's others do the work. In the old systems, most information had to be maintained by my customer. In the new system, they allow external users to maintain some of the data, decreasing their labor costs.
• More user-friendly. The old version was difficult for external users to understand, which was bad PR for my customer plus it wasted their time trying to explain it to end users.
• Built-in flexibility. The previous systems used a lot of hard-coded values. With the new system, many items are stored in the database, including several look-up values AND the validation error messages. My customer will be able to tweak these values on their own without paying for additional programming resources.

When I look at this list, it makes me wonder: why didn't they do this sooner? The truth is that it is often difficult to know how much these kinds of inefficiencies are costing an organization. I suspect that if my customer had actually looked at this critically previously, they would have realized how much the productivity and opportunities lost were costing them.

How much are your work-arounds costing you? Are you re-keying data into two systems because there isn't an interface between them? Are you manually producing reports for your customers that could be generated automatically? Are you losing customers because you aren't able to respond as quickly as the competition due to your manual processes?