Problems being a "lone developer"

I have worked in IT for 5+ years now and one thing that seems to be a perennial problem with the industry is its gravitation towards the "lone developer".

What do I mean by that? From personal experience I have been working alone for most of the 5+ years. Even when working in other companies I spent a large amount of time working on my own on problems that others had superficial input on.

Why does this happen? It is true that while working on a complex problem, a developer will need time of uninterrupted concentration. However, in my experience, a small period of concentration can lead to hours of silent working on problems that are more mundane. This then leads to days, weeks or even months without proper communication. Is there a problem with that? 

Firstly, developers, whether we like it or not, often think of a problem from a different viewpoint to the end user. Therefore, regular and efficient communication is a must if a project is going to be a success. 

Second, and this is more particular for the freelancer or other home-working developer, motivation can be affected by a lack of communication. Often I find myself most productive when I have a clear idea of what it is I am building, and this happens most often after a meeting with the clients. In fact, perhaps the most progress with any project is made in the first few days/weeks after the initial meeting with the client. Therefore, for regular productivity and motivation, regular communication is a key.

From personal experience, these problems can lead to ruination of a software project. Communication in many ways is like a bike on a steep hill. While you are pedaling the bike is making forward motion, however, once you stop, the bike loses momentum and instead of remaining still, will quickly move backwards. As soon as a client and developer cease communicating, the project starts to lose momentum and it won't be long before the project starts to make backwards strides. 

So how can a developer that doesn't work with a team of developers, avoid becoming a "lone developer"? We mentioned regular and efficient communication. What does that mean practically?

Regular Communication

Does regular communication mean that you have to be constantly talking? Of course not! If that was so, you would never progress on a project as you would only be talking about it. Rather, one definition of regular has an excellent ideology that we would do well to think on:

arranged in or constituting a constant or definite pattern, especially with the same space between individual instances.

So regular meetings, that are arranged regularly, is really what we are talking about here. It may be difficult to think about certain aspects of the Agile methodologies as a developer working on their own. However, there are certain parts for sure that can be taken on board.

One that I am finding to be particularly helpful is a sprint review meeting with the client. This is usually no more than an hour of time spent with the client, showcasing what you have achieved in the last set amount of time (usually 2 weeks), and gaining necessary feedback on the state of development. What does this achieve?

It means that I don't spend a long time redesigning a full form or web page or mobile screen, only to have the whole thing rejected based on the client's perspective. Perhaps more importantly, it helps to get useful feedback.

If there are a few issues with a screen, a client will feel free to let me know what they are. However, if the whole screen is different from what they wanted, then they will mentally lower their expectations of you and start to look elsewhere for the solution to their problems. Which leads us to our next point.

Efficient Communication

How can you make the time that you spend with a client meaningful. We have all heard of or even come across clients who really don't know how to articulate their requirements. However, some of the blame lies on us as developers, as we have an equally difficult time in articulating what our vision is for a project, in the vernacular.

Again, it is good for us to look at some points in Agile. Could it be that just setting a theme for a meeting will be the incentive that we need to keep it on track? I know that I have spent hours in the past discussing functionality, only to realize that the conversation has lead to features and screens that either are not built yet, or in some cases, never will be built. Unfortunately, this leads to frustrated clients, muggy waters in terms of requirements and elongated project development times. 

Something that I have found helpful is to have meeting set aside for specific subjects. For example, imagine a largely complicated form that takes information from 3 or 4 other parts of an application. If we are working on the save routine and the business logic that goes into that screen, how easy it would be to become side tracked by looking into what the other 3 or 4 screens do to handle the data they receive. Why not set a meeting to discuss one screen and only one, and then if you need to look into the functionality of other screens, then set a future meeting aside for that purpose?

Another important aspect is to have a chairman of the meetings. I'm not suggesting that the meetings be chaired like a local council meeting with minutes and over-formality. However, I have found that often one person can be half way through a thought and then be interrupted by another person with an "urgent" question. Having some formality to a meeting will help it to run smoothly. 

In conclusion, there are too often failed projects that result from "lone developer" syndrome. I think it would be good for all developers, especially those who work apart from their team, or perhaps work alone, to keep in mind communication to the greatest extent possible.