The challenge is not the how but the what

Some programming is highly technical but a typical website or web app is actually fairly simple and rountine. The challenge is not the programming itself but working out what to build in the first place.

A project is made up of 1000′s of decisions

decisionsThere are some major decisions:

What is the core problem we are trying to solve?
Which features provide the most benefit to our users?
Which are the nice to haves?
What personality should we go for?

And there are thousands more micro decisions:

Where should this button go?
What happens when I click it?
Which fields do I need to place emphasis on?
Which screen comes next?
Does this copy feel right on this form?

It is these decisions which make or break a project. The difficulty is knowing the answers.

Open source inherently knows the answers

scratchingOpen source is the most ‘natural’ way to develop. The programmer has a problem which current software doesn’t solve. So they code a solution. The projects are self selected. The developer is scratching their own itch. All the project decisions can be answered by the programmer.

When I built FormIgniter I was both the user and the developer. As a result I knew exactly what it needed to do. I could tell if design decisions weren’t working. I added the things I wanted. I left out features that I considered ‘fluff’ or just mere ‘bells and whistles’.

I took a stance and created a piece of opinionated software.

It is this ‘developer and user in one‘ combination which has lead to the wealth of high quality open source software.

But client work is different – someone else’s itch is being scratched

I’m continually amazed at how many companies miss vital flaws in their product or service, simply because they don’t use it every day. – Ryan Carson

Ryan makes a very good point. Usually when working for clients I am not the end user. I am unlikely to use the website or service at all, let alone on a daily basis.

To make informed decisions I need to either do a lot of research or be in constant consultation with my client. There usually isn’t a ‘Research’ budget on web builds and constant collaboration creates an undesirable communication overhead.

Even if constant collaboration was possible the client might not actually be the end user anyway.

For example recently a project to build a database for hospital GP’s came my way. I personally have no knowledge of this area. As a developer and not a GP I will never use this system myself. The client knows this area but they are not the end user. They commissioned the work on behalf of a hospital and will never actually use the system on a daily basis.

Between us there is a major knowledge gap.

So how do we close this gap?

Specialise. Work on projects where you are the end user.

I work closely with a web agency who solely work with independent documentary films makers; a niche within a niche. It is a decision which I have often thought would hold them back. Limiting your client base so severely seems like an obvious ‘business 101′ no no.

But working within such a small area has enabled them to develop an intimate knowledge of the industry.

They learnt the challenges and problems independent filmmakers face. They started to think like independent filmmakers themselves. In fact a few of them actually are. Over time they have created solutions. The tools they build are good because they know what film makers want. They don’t need to ask questions. They know the answers themselves. Clients come to them because this knowledge gives them an unique value within the marketplace.

So choose an area that you are passionate about. An area where you are naturally the end user. Get to know the field. Get to know the problems clients typically face. Work out the solutions.

Become a developer with market knowledge. Your work and satisfaction will improve because despite doing client work you will be scratching your own itch.