The Challenge of the Single Developer

He started off by asking the following:

I am currently pitching for my first big piece of work, and have been pondering the question of ‘single person risk’. Do you have any advice or suggestions to make in this area? How did you deal with it with your recent enterprise-level app?

I wrote back to him, giving my thoughts. But, I also wanted to share my thoughts here on the blog, as well as to take the time to gestate over the questions and give more consideration to the questions posed.

As a freelance developer, I can see why a company might be concerned about the question of single person risk. Given just how important, even critical, software is to businesses today, want they need to have is trust, reassurance, and continuity.

It’s All About Trust

They need to be able to trust that their investment, in whoever’s developing the software, is well placed. They need to have a sense of reassurance that the team’s not just going to disappear, stop working on the project, give them time only when they can or feel like it.

In essence, they need to know two things:

• That the software will be developed properly and meet the provided specification
• That it will be maintained over the course of time

How the software’s developed, to an extent, is irrelevant. I say to an extent deliberately, as if they could develop it in-house, then I’d suggest that they would have. Since they’ve not , then I’d suggest that they are not able to. However, it is important, but I believe it’s not the main point to focus upon. But I’ll come to it later.

Going back to the two core points, as an individual software developer, or as a small team, you need to understand that a business may not want to deal with you because they may feel that the risk is too high. To an extent, that’s an understandable preconception to have.

After all, there’s always the question of what happens if you fall under the proverbial bus or, in software terms, how high’s the bus factor? If you’re not familiar with the term, here’s an summary from Wikipedia:

In business management, and especially in the field of software development, the bus factor is a measurement of the concentration of information in individual team members. It is also known as the lottery factor, truck factor, bus/truck number or lorry factor and connotes the number of team members that can be unexpectedly lost from a project (“hit by a bus”, as it were) before the project collapses due to lack of knowledgeable or competent personnel.

What Happens If Something Happens To You?

So the fewer the number of developers having intimate knowledge of a project, the higher the bus factor. Said another way, if it’s just you, and something happens to you, then there’s a high risk that the investment in the project will be lost.

At that point, what happens to the business’ app? Where do they go and what do they do to not lose the investment they made up until that point? Can they go somewhere else? Can they find another development team? Can they salvage the investment? Can another team pick up where you left off?

Or do they have to start all over again? Then there’s another potential worry; what happens if you take on too much work, and can’t give them the attention which they need (or feel they need).

Conversely, what if you decide that your heart’s no longer in it, or you have a situation arise where you’re no longer able to give it the commitment it needs? For example, a member of the family takes ill, you are diagnosed with some chronic or debilitating illness.

What I’m not suggesting is that it’s either not possible, or that businesses would always be too risk averse to deal with an individual developer, or a small development house. But I can see how they may be concerned.

## I Do Believe In Freelancers

Now that I’ve laid out perhaps a set of worst-case scenarios, I don’t really see a lot of, effective, difference between small (even one-person) operations and larger businesses. All of them have associated risks.

For example, at an un-named business I worked for some years ago, the IT department had support contracts with two, large, external vendors. When something would go wrong, we’d call up the one which we thought was responsible for the issue.

Often times they’d deny that the issue lay with them; instead saying that the issue lay with the other vendor. When the other vendor was contacted, they’d engage in the same finger-pointing.

Regardless of where the responsibility lay, our problem wasn’t resolved, and the business wasn’t getting value for money. Yes, the companies were large firms, with global reputations. But that didn’t mean that our issues were resolved in a way that we thought they should have been.

So if you are either a freelance developer, or running a small software development shop, here’s some suggestions on how to counter perceived drawbacks and negative perceptions.

Build Up Your Reputation

Firstly, focus on one thing - building a perception of trust and reliability. To me this is essential. I came across this years ago, a friend of mine, who I was helping out with a server installation, said words to the effect of:

“I don’t care how you do what you do — I really don’t! I just care that you get the job done. If you inspire me with confidence in your abilities, in your skills, in your knowledge, that I’m safe in your hands, then it doesn’t matter what you do, because I believe that you’ll come through for me”.

The words really rocked me, because at the time I was a typical technology person. What mattered was the technical solution. Would the client accept the choice of technologies I was proposing? Would they only accept a certain set of choices?

His words shifted my entire technology paradigm.

And it makes complete sense to me. Going back to my earlier proposition about businesses coming to you because they need your skills, they have to trust you. But let’s take ourselves out of the equation for the time being.

Does it really matter, to the client, what you developed an app in, if it meets their needs, and works reliably? I’d suggest not. It’s only interesting to a precious few how the application works under the hood.

Long as it’s delivering value to the client, reliably and consistently over time, then how it does what it does - to them - isn’t that important. That side of the equation’s only important to us. That’s my core suggestion.

Some Specifics On How To Do It

At all times, ensure that you’re presenting a perception of trust and reliability, and that you’re a safe pair of hands. Give them every reason to trust you, and no reasons to doubt you.

I suggest reviewing all the non-technical aspects, such as how you communicate, the words you use and don’t use, even the fonts and colours. Do they communicate these core values? Or do they communicate something else?

Then look at your level and regularity of communication. Are you regularly in touch, or do you come and go? I’m not suggesting that you have to overload them, even deluge them, with updates. But are you there on a consistent basis?

When you’ve got those nailed, start seeking out testimonials that emphasise how reliable you and your business are. Build a track record of quality projects, ones which you can point to and share. I’m not talking in some gimmicky, door-to-door salesman kind of way, but in a genuine way.

There’s a host of other suggestions. But I think these make for a good start.

The Technical Considerations

Now let’s give some more thought to the technical aspects. What is the technology mix you’d use for a client’s project? While it’s great that you may keep up with all the latest trends, and enjoy living on the bleeding edge, that may not be the best choice for your customer.

Let’s say that Google’s Go was only just starting to seep in to the collective developer consciousness. It’s a compelling language, to be sure. It has a host of great features, and is a simple and concise language.

What’s more, it’s designed for the type of development the client needs. You could also choose a well known and well supported technology mix, such as a LAMP stack, and on top of that use a well known, and well supported framework, such as Zend Framework or perhaps Laravel.

Which is the right choice? I’ll be honest, this is a little hard to give a clear yes or no answer on. So, instead I’ll play devil’s advocate for a moment.

## A Hypothetical Situation

Let’s say that you live in Brisbane, Australia, my adopted hometown. What’s the uptake like there of Google Go? What’s the uptake like in the wider Australian, developer, community? If you get stuck, how likely is it that you’ll be able to get help? What is the level of support for plugins and third-party packages like?

Are there people in the community who regularly blog about the language? Are there active communities on IRC? Are there thriving forums which you can lurk (or participate) in?

Let’s continue with the hypothetical that Go was still quite new. The likelihood that all of these points, or most of them, would be in place, would be minimal. Yes, they’d be growing, but they’d not be there yet. Is that something which you’d be comfortable with? Or, are you a sufficiently skilled developer that that wouldn’t be a problem?

Contrast this with going with the older, more established set of solutions, those being either Zend Framework or Laravel. Both of these have large developer communities, are well known, have been supported for a long time, and are likely to be supported well in to the future.

They’re also known quantities. As a result, there’s a much larger sense of confidence that you can get help if and when you need it; and that someone’s likely dealt with your specific use-case before.

For what it’s worth, I was developing with PHP when it was relatively unknown, and Microsoft’s ASP (classic) was the well known and well supported option.

Here’s another, potential, benefit. By choosing a technology mix like this, then the business has reduced risk, should something happen to you. If you build the project on a well-established technology foundation and something happened to you - whether that be a change of pace, family upheaval, or health complication - then ability for them to locate a developer, or development team, with knowledge of the technology stack is much greater.

Given that, the potential loss, or write-down, on the investment up to this point is greatly reduced. If, however, you’d gone with a relatively new or not so well known technology stack, then it’s less likely that they’d be able to find a follow-up developer, potentially requiring a complete rewrite. I want to stress that I’m not against newer technologies.

I don’t want to give the impression that I’m an ultra-conservative person, only trusting that which is well-known. As I said, if I was, then I’d have gone with the prevailing “wisdom” 15+ years ago, and learned only Microsoft technologies.

Instead, I used PHP and Redhat Linux. Given where I’m from, that was well and truly against the grain.

In Conclusion

What I am suggesting, is to be open-minded, and considered in your thinking. Are your skills sufficiently developed in the technology stack you’re considering using?

Should you go with a “safer” option? What is the likelihood of something happening to you? Are you skills not quite sufficient, but through this project you’ll be forced to grow and make them so?

Ultimately, only you can ask and answer these questions. It’s your business, your potential customer. Whichever way you go, there are no wrong and right answers. And seemingly wrong decisions can turn out to be right in the longer term. All I suggest, is that you go bear these things in mind.

Then give it your all!

CC Image (background of main image) Courtesy of Terry Johnston on Flickr