Developing Programmers .com

So what does a software consultant actually do? I have asked a few people this question and the most common response seems to be a stunned silence. Several years ago, a major software consulting firm had set up a stand at a job fair I went to at my university. I asked them about what they do. I was told, “If you have to ask then you shouldn’t be here”. Strangely, I thought that if I didn’t know then a job fair was a perfectly good place to find out. For some reason I never became a consultant, I figured they were basically commando programmers who go into a job too late, patch up a problem, and escape before the consequences of their short term fix become apparent.

Luckily, not all consultants are so rude. I got talking with a consultant at a dinner recently (hi Vivian!) and she suggested there was a lot more to this “consulting” gig than I had been giving it credit for. So, I decided to try again and ask a couple of consultants about what they actually do for a living. After all, what’s a web site for if you can’t learn something new and explain it to others at the same time?

I sent out four emails and got two replies back, one from Ben Golding and one from Kornelis Sietsma.

Ben Golding is the Managing Director of an Australian consultancy company called Object Craft. Object Craft are a small, highly skilled and informed team of developers with over 50 years experience in application design, deployment, debugging and maintenance across a range of industries and platforms. I emailed Ben to ask him about what it means to be a consultant.

Kornelis Sietsma (aka Korny) is a friend of mine who currently works for Hyro, and has worked for other consulting firms in the past. Hyro offer a diverse range of software development and consulting services, particularly for internet based business and communications tools (the buzzword they use is “online services”). I caught up with Korny over breakfast and we went over Ben’s answers together, so Korny could add his thoughts.

I synthesized the conversations together into this picture of what consulting is all about:

So what do consultants actually do?

Ben:

It seems kind of banal but our customers buy our time from us and we do what they ask us to. They purchase access to our experience and problem solving skills and whether they want to use that to guide them in making decisions or to simply use us to fill gaps in their personnel is up to them.

We work hard to try and stay focused on our core business which is programming.
We often get requests to do things outside our core business which we decline.
For example, we were asked whether we would consider hosting a backup server for one of our long-standing clients, we could do it (easily) but we said no because that’s not our business.

Korny:

Overall, I basically agree with Ben on this.

It’s probably worth pointing out that not every company is as good about keeping to the main software development work. Sometimes I’ve been told to do things I just plain didn’t want to do, like data entry. That really shouldn’t be a consultants job, but whether you end up having to do it depends on the company you work for. My current company is a lot better with this than some I’ve previously worked for.

What kinds of things do clients typically ask you to do? Do you often find yourself just “temp staff?”

Ben:

There are a few kinds of work people come to us with:

• The “commando” style programming work where customers have a specific need for expertise without the need/desire/means to employ
  those people for extended periods of time.
• To bring in specific expertise in, say, in application design or specific problem solving where there is little or no need to try and keep the expertise in-house. The value is in the work that’s delivered.
• To act as an out-sourced development team without incurring the costs that involves. For example, we have a customer who are experts
  in their core business (financial services in this instance) but they
  don’t have the workload to keep a programmer busy full-time, nor to
  be able to manage technical resources effectively within their
  organisation. We provide that service, as well as being able to
  offer coverage when the programmer goes on holiday or is away.
  These sort of customers often have tried to hire programmers who solve the immediate job at hand and then sit on their hands until they get bored and leave, leaving the company in a crisis.

Korny:

Needing once-off work is extremely common. A lot of my clients have wanted a software system set up and customized for them, and once it’s set up that’s the end of it, they’re happy. They don’t need someone permanent for that.

Some clients are just overpaying for outsourced software development teams, either because they think they need consultants, maybe because they’ve had a good experience with consultants before. Sometimes they hire consultants as expensive contractors because they are large enough companies to have specific budgets for things, and they might have used up their budget for “programmers” but not used up their budget for “consultants”. It’s inefficient but at some places it’s how things are done.

Originally, consultants were experts in a particular product. For example, Candle Corp. provided a set of mainframe management tools and also offered consultants to do configuration of the tools and training for their tools. This is Product Consulting, which works well where you can set something up once and then basically leave it alone.

There is also General Consulting, where anything someone is an expert in might be something they are asked to do. General consultants might write an evaluation of what’s required for a task or how well a job was done. Talking to a consultant before and after hiring a development team to write something for a client will help the client get value for money.

A third kind of consultant, perhaps called a Specialist Consultant, is an expert in some system or hardware that an in-shop development team needs to use. I’m often hired as a Java guru, and I’ve also been asked by Samsung Korea to help out with a Java based RFID tag where they needed someone who knew about the hardware.

There are Contractors, too. That’s where people are hired to do software development. They are often called consultants but it’s really a different thing. Contractors generally get lower rates than consultants, and a job will usually last 6 months to a year. I’m not sure why it’s called consulting. In theory you’re getting experienced people. I guess contractors are more likely to be off-site development teams, but consultants are like a gun team of programmers who come and work directly with the client. It’s like having your own in-house programming team, just not full time. I guess the difference is the people skills, you’re own your own with the customer and have to work out on your own what their requirements are.

Finally there is Fire Fighting. This is where you’re called in because something has already gone wrong and the customer is hoping you can fix it. For example, they might have sacked the people who messed up a project and now they need someone to come in and sort it all out. Often they could have fixed it themselves with more time, and they’ve been caught out by the “Mythical Man Month”, where they wrongly assume that more people can make up for not having more time. In these cases there is usually no specification or design document. In some ways it’s good. You’re there to fix an emergency, so you can get away with an ad-hoc fix to get them past the crisis and leave them with advice to spend the time to get it right once the crisis is over. It’s not up to you to see what happens next.

When do people usually call in consultants?

Ben:

Erm, usually too late?

Korny:

I’d have to agree with that.

Ben:

An inexperienced programming team (or even an experienced team) should call in consultants (as one option; hiring or training are others) when they recognise that their skill set is missing something critical. Ideally, part of the consultant’s role will be a transfer of knowledge to the staff so that they can learn from it.

Korny:

If there is a technology you don’t know and there’s a deadline looming, it’s better to call consultants. Then the job can be done quicker, and you’re less likely to make “first time” mistakes. Ideally, the consultants will teach your team about the skills as they work so you are able to keep things going when they leave. For example, if your company is moving from Sun to IBM servers and there is no time to spend the time messing with the IBM systems to learn about them.

People might also call consultants at the start of a project, for example if they know they have to use an unfamiliar technology like Oracle they can make sure their design is realistic by talking to people who have used Oracle in practice not just read the manuals.

In general I think it’s better to train your own people in the technologies you use. The “Mythical Man Month” describes how calling in more people for a late project will just make it later because of the communication and organization overheads. It’s better to allow enough time in the first place, and if you’re using consultants then use them to train your people early, not to step into a crisis. At crisis time the last thing you generally want is more people.

Some of my readers would be wondering about becoming consultants. What skills are helpful for people thinking of becoming consultants?

Ben:

The single biggest help we’ve found is having experience across a range of areas. Coverage of specific application domains is important but being able to recognise problems from a high level and then know how to address them is where the real value lies.

Korny:

That’s a very good point. Actually, I have a slight issue with new programmers becoming consultants. It only works if they have serious expertise in a particular tool, like say MySQL or if they are experts in the domain an application is being written for. Otherwise people are paying for general software development experience which new programmers simply don’t have yet. If they work for a consulting firm, though, a new programmer might be a junior part of a consulting team. Then it’s OK because they’re really working as developers in a team. They can get experience in the shelter of the team before they are called on to depend on just their own experience. The team gives them some clear structure to their work, but being a junior member of a team generally comes with less pay.

There are pros and cons to consulting as a career.

Some of the pros are:

• You get to play with all kinds of different technology.
• You become broadly experienced and can continuously train yourself.
• It pays well.
• You can walk away. After the 3 to 6 months, you’re not stuck with maintaining something that you wrote under pressure.

Some of the cons are:

• It can be very stressful.
• You are typically thrown from job to job with very little recovery time in between.
• Some consultancy firms will exaggerate your skills to the customer to get the contract, which can become a problem for you. Some companies are much better than others.
• Although you get broad experience, you might feel frustrated that you never get deep experience with any one technology.

Then there are aspects of the job that can be pros or cons depending on how you look at it:

• The kinds of situations you are put into depends a lot on your boss’ honesty.
• You have to present well and communicate well with clients.
• You have to interact with a lot of people, generally when they are already under pressure.

Thanks to Ben and Korny for a fantastic insight into what it is to be a consultant. I have a much better idea of what consultancy is all about, when to hire consultants, and who might want to become a consultant. I think we’ve also highlighted some things to watch out for: consultancy companies are not all made equal so it seems worthwhile to shop around, whether you are hiring or aspiring to be a consultant.

Korny mentioned “The Mythical Man Month”, which is one of a collection of software engineering management essays by Frederick Brooks, Jr. I have started reading this book and it has fantastic insights for programmers and managers alike. When I finish reading, I will write about the book here.

A forum topic has been set up for discussion of this article.