Software developers use many tools to support their work. They coordinate with their teams on code hosting sites, interface with non-developers in project management apps, use microblogs to network, and learn through Q&A sites and podcasts.
They do derive value from those tools — but what problems and challenges do they have to cope with in return?
In a previous blog post, I reported on a study I conducted with colleagues: Through a large survey, we learned what tools developers think are important to them and what value they provide.
However, we didn’t yet discuss any problems that might come with using those tools.
In our survey, we asked our survey participants about any challenges they might encounter.
To make sense of all the responses, we coded, sorted, grouped, and then categorized them. In this post, we’ll look at a few of the recurring themes. Our paper — linked at the bottom — has more details.
Distractions & Interruptions
Entertainment sites and apps can be pretty distracting and pull people into a rabbit hole of distraction and procrastination. Developers are no different:
Social Networking Websites like Facebook are the worst ingredients for good concentration in general.
But even when distractions are work-related, they can be counterproductive: sometimes work needs to be deep and goal-oriented:
If I spend a lot of time talking with other developers about the best way to do things or reading articles on social sites, I end up constantly refactoring or optimizing code instead of making progress toward the functional requirements of the project.
Notifications can be useful, but they also make it easier than ever to become distracted:
Notifications: when used in a moderate way, it is fine, but when overused, it is a distraction for developers.
They also make it harder to get started and focus in the morning, since they accumulate during the night:
Too many emails from project coordination tools can easily waste 15-30 minutes only to go through them all in the morning, specially when I’m involved in more than a few projects simultaneously.
Keeping Up With Everything
Many of our study participants think that developers need to keep learning new practices and technologies — or else risk becoming obsolete. Keeping up with new things is an ongoing concern:
Staying cutting edge is a never-ending task.
Several of our respondents are unsure what channels to watch:
Knowing where the activity is. Some days, Hacker News might be the best place to follow. Another day, Twitter might be. Another day, GitHub might be where I should look. Another day, it might be a site or network I’m not even aware of.
We had previously seen this challenge of having to keep up in our work on how developers use Twitter.
The tools for keeping up with activities on projects are seen as inadequate and in need of improvement:
In a big project (WebKit, Mozilla, etc.) it can be hard to filter for only ongoing work that is relevant. Most legacy UIs are terrible (Bugzilla) and new ones (GitHub) lack features for large-scale development.
Some more recent tools such as Slack or Hipchat address this to a degree, though. Especially bots and other integrations seem to help consolidating relevant activity:
We use HipChat with Hubot that watches our GitHub activity. It’s wonderful because our entire team can be instantly notified about who’s doing what on which repository, and we’re all in communication via mobile and desktop with the same feed.
Imperfect Tools for Talking About Code
Developers have difficulties sharing and explaining code using their existing tools. Often a combination of different tools would be needed:
Many communication tools (email, IM, etc.) are not especially good for talking about code. Generally in any given conversation I’ll end up using several tools, e.g., IRC + a paste-bin (GitHub Gists), to effectively communicate ideas.
There are some tools that attempt to create a shared programming workspace, but they’re not yet quite there:
The biggest challenge in soft-dev for me is four-fold: communicating the idea (Hangout), managing the idea (Trello), logging the implemented idea (GitHub), and explaining the implemented idea with the team (Nitrous.io). The first three solutions are pretty solid. It’s the fact you can’t always sit right next to someone and show them the code and explain how everything works that is the most challenging part. Cloud9, Koding, Nitrous, etc. are all trying to solve the last problem.
Another participant complained about the non-existence of such tools:
Live collaborative coding tools. For example, we can currently edit a document collaboratively in Google Docs. If we can have an IDE/tool like that for coding too, that would be useful.
Apparently awareness of available tools can be a problem as well.
People Are Difficult
A poor attitude or a lack of willingness to collaborate can be problematic — and it doesn’t matter what tools you use in such cases:
[Tools] still don’t solve the difficult people problems.
As one survey respondent explains:
Tools facilitate good processes and interactions between individuals who are willing to collaborate and cooperate. They don’t make people willing to cooperate in the first place; in these situations they actually get in the way of identifying the root problems and dealing with them. People can hide behind GitHub better than they can in person.
A sub-problem is lacking adoption. Getting people to use a collaboration tool can be problematic as well:
The biggest challenge is getting other devs to be open both with their work and to new ideas.
The social transparency that many channels create introduces other issues.
Developers can feel intimidated, either because they’re worried that their own contributions or skills aren’t good enough, or that others may not react well to their contributions. One participant told us:
The biggest thing I fear in my work is that I’ll say something that is not 100% technically accurate or could be misinterpreted. Other developers are utterly merciless, and I have thin skin. Whenever I post something on HN or Stack Overflow, I find that I feel anxious that someone will tear me a new one over some oversight in my analysis.
These problems lie much deeper than new tools: the characteristics of some channels require us to, for example, rethink what failure or being wrong mean — to us individually, to organizations, but also in more global communities.
Tool Literacy
Every tool has a learning curve: you need to learn how to make it do what you want it to, on a technical level.
But you also need to learn common idioms and conventions that make the tool easier to use and easier to talk about.
These things usually take longer and are much harder to learn. How people in an organization use a certain tool has to be figured out, and even then it will evolve and change. It might even differ between different groups in an organization. And conventions like these are often left tacit, at least in part.
When using a tool, different people will usually be on (at least slightly) different places on the learning curve at any one time.
This can be especially problematic if the point of the tool is to allow those people to interact with each other:
The main challenge for me is the interaction with people who are not literate enough to use the tools I consider standard.
One common example for such a dissonance is git:
Also, Git is a critical collaboration tool, but it is not well understood by many of the programmers I interact with.
Developers do recognize that learning these tools is a challenge:
I still don’t understand how to do simple things in IRC and often don’t bother because of the perceived effort involved — much easier to post on Stack Overflow. With tools like GitHub, there are similar issues (like how to submit patches) although documentation is improving.
But even if this issue can be worked around, adopting new tools can throw off a carefully constructed balance:
The biggest challenge [about using] social tools during development is when a new one is adopted into the mix; the learning curve associated with a new tool eats time unless the program is intuitive and pointed.
And as we saw, a group often needs time to negotiate how they want to use a new tool.
Many Channels Create Fragmentation
Developers have so many different tools at their disposal. This can also lead to having too many channels through which work happens:
One of the things that bugs me most is multiple media. At any given moment I can get a chat, an email, a text, or whatever — wish it was more streamlined.
This fragmentation isn’t necessarily due to the sheer number of channels available. It can also occur because of inconsistent or poor adoption of a channel: for example, if a company uses Slack but a few people continue to use IRC instead.
One respondent suggested that better integration between channels could help and is being worked on by some companies:
One of the biggest issues with fragmentation of the communication options is that there are so many different ways to communicate that it’s harder to find it all in one place. Important communications get lost; key people don’t see them; they can’t be retrieved by a single search tool. Companies such as Slack are attempting to solve this problem, but it has a long way to go.
Very general platforms such as Slack attempt to be the operating system of the workplace. All the other tools and channels are being fed into them, and can often even be controlled from within them.
Many of these changes have been underway for quite some time, but the recent rise of integrations and bots will probably have a significant and lasting impact on how developers communicate and collaborate.
There Is Too Much Information
Fragmentation is one drawback. Another strong effect of making it easier to communicate is that there is more to process now.
For developers, it’s challenging to find the “signal in the noise”. The “explosion” of available channels has led to an increase in volume and duplicate information posted in multiple locations.
This is particularly difficult for developers working on multiple projects in which different tools are used:
The variety of tools, and the need to switch context and tool set between various sub-projects, adds a lot of cognitive overhead.
There is also a fear of missing important information:
Too many channels means that needed or interesting information disappears, and going through all of the channels you mentioned is impossible in limited time.
Although poor channel integration that leads to information fragmentation is one issue, the channels themselves further promote an increase in the quantity of communication:
I feel that social tools largely present information in fragments, with many different approaches and styles and agendas, which makes it time-consuming to stitch together a working knowledge of technologies I’m learning.
The diversity and velocity of information makes it hard for developers to keep up with new technologies:
There definitely is information overload. People think I’m joking when I mention the ‘javascript framework of the day’.
Developers try to stay up to date on these new technologies, but the availability of so many different news sites and aggregators means they are inundated with content. This can affect their producivity, too:
The News overload via Aggregators (Hackernews, Reddit, Digg, Slashdot, …) affects productivity. I don’t use too much social networking (Facebook or Twitter) as they are a huge time-sink and sheer noise as far as technical development work is concerned.
It’s Unclear What Information Is Helpful
With so much information available now from so many different channels, it also becomes harder to assess and filter for quality:
Judging the reliability and credibility of sources can be a challenge as information changes quickly and isn’t always correct.
Some of our survey respondents were particularly concerned with social sites:
I sometimes feel the lack of quality content on social networks and Q&A sites — especially when it comes to incompetent answers to questions I ask. So the challenge is to filter the information you get from all of the sources.
Developers were also concerned that they had to assess and filter out contradicting, inconsistent, or obsolete information:
Technologies are moving so fast, and most of the content on the Internet could be outdated quickly. It’s sometimes hard to filter that outdated information.
Usually, information tends to have some sort of context or history in which it is presented. However, in many channels used by developers, this context is sometimes hard to acquire, making assessment unnecessarily burdensome or even impossible.
Next Up: Recommendations
We saw many challenges: some stem from the tools themselves, some from the people, and some from the interactions between both.
But what can we actually do about these problems? Do we just have to accept them? Or do we have to drastically cut down on the number of tools we use?
That’s what the next and final part of this blog post series will talk about. We’ll provide recommendations on how to cope with many of the challenges above. Please check back later — or just let me notify you. 🙂
Note: the journal “Transactions on Software Engineering” has recently published an extensive report on our study; you can read the preprint here.