Tips for Hiring and Working With Programmers

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?

When I worked for a consulting company, one of the challenges we faced was finding work that was compelling to our consultants. Most technical consultants enjoy a technical challenge, and are doing consulting work instead of working at a 9 to 5 company because they like the variety and technical challenges that are available when working for a consulting company. If you didn't keep your staff challenged, they were likely to leave for other opportunities. However, you are not selling services to geeks, but to business people who are just solving business problems.

Today a friend of mine who owns an HVAC service company was telling me that they have the same challenges in his industry. He has found a niche in gas fireplace installations, which apparently many organizations do not actively pursue. Why? The service techs don't like the work - it is too boring!

There are some unique problems to the technology businesses, but not as many as we think.

Here's a great way to make your software project more complicated: don't use an issue tracking system. Issue tracking systems provide users/testers a centralized location to identify system bugs, questions and requests.

You may think that you can easily do this via email, and for very small efforts you are right. However, for most projects, tracking issues via email will quickly become a tangled mess of long threads that are impossible to effectively track.

If you want to lose track of what issues are fixed vs. what is still outstanding, by all means you should skip using an issue tracking system. (Perhaps you might also enjoy carving each bug into a big slab of rock, too.)

On the other hand, if you want to be organized and suffer less, find a nice issue tracking system. These days, I'm using Unfuddle, but there are plenty of others.

If you are non-technical, hiring a technical resource can be a bit daunting. How can you evaluate their technical skills when you don't know an IP address from your elbow?

Well, you can't actually. There is no way you can (on you own) evaluate someone else's technical expertise if you don't have any. Never fear, however. Instead, you can evaluate them on other criteria. Here are some ways of identifying someone who will do a crappy job of writing your software.

Is their written correspondence riddled with typos? If they aren't careful when communicating with you, a potential client, believe me, they won't be careful with your code, either. Poor communication is a great indicator of a sucky programmer.

Do they ask questions? Developers who don't care about your needs won't ask you any questions about them. They'll ask a few questions, and make a lot of assumptions. If they don't ask any question other than the billing rate, they will suck the most.

Do they have a plan for ensuring quality? A developer who sucks will look confused if you ask about their plan to make sure they develop quality software. Programmers who don't suck can tell you about the unit tests they will create, acceptance tests they will help create, or perhaps even a manual test plan they will provide to help verify some level of software quality.

Do they claim to be a guru at everything? Programmers who suck will often tell you they are experts at any and every technology you question them about. Good developers know that you can't be an expert at everything, and that claiming to be so is dishonest and foolish. If you really want someone who sucks to work on your project, liars are a great choice.

My brother and I took a rode trip a few weeks ago with my 3 year old nephew. He handled the 5 hours of round trip riding fairly well, with barely a complaint. On the trip back, my brother asked me to give him his coloring book and some crayons - he didn't want his son bored.

Since my brother and I were sitting in the front, and my nephew was strapped into his car seat in the back, we weren't monitoring him closely. Big mistake.

My brother glanced back and realized his son had been drawing all over the vehicle wall. Oops.

This is how developers sometimes handle end-users. We give them the tools to do a lot of damage, and then we are surprised when the users accomplish that task.

Developing greate software requires imagination. We need to think about how others will try to use it. And we need to think about it not just as someone who is trying to accomplish a specific task, but also as a creative prankster might.

And then, we need to try to protect them (and the system) from doing anything destructive.