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.

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

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.

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.  

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.

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…

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 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.