We started CodeStream because after years of working on news feeds and chat collaboration solutions, we realized that we were not applying what we knew about real-time collaboration to our own development processes. The team at CodeStream has been together for a couple of decades. We created a social network called Multiply, and a team chat solution called Glip. One day last year, as we were discussing code, it hit us that the available solutions, even our own previous efforts, were just not doing it for development teams. This post is about how to make team chat a lot better for hackers.
Choosing the right mode of communication is important in order to get the best outcomes in all of our interactions. Love letters are more powerful symbols of love than text messages, while long-form, nicely-formatted documents are better for business proposals than just a plain email. Talking about code outside the development environment is just not the best way to communicate for developers.
In this post we will focus on understanding the power of team chat in context. In particular, we will explain why we see development teams under-communicating and what problems that creates. It’s not that there isn’t a lot of chatter out there. We just see many opportunities to improve on the existing approach, and in the process, we hope to change the way developers write code as a team.
We were right there during the team chat explosion. In 2012 we witnessed the emergence of Slack as a powerful and widely adopted replacement for what had been up to that point an email based world. The same year we introduced Glip, and while there were significant differences in approach and philosophy, both products shared much in common. We sold Glip in 2015 and the team stayed on with the acquirer for a couple of years to help with transition and integration. Slack became the industry standard and spread quickly through the development community.
Slack has set a high bar for user experience, number of integrations with other apps, and growth trajectory. As of September 2017, Slack had 6 million daily users with one third of them paying for the service. This is Slack’s promise to its users:
“Slack takes the hardest part of all our jobs — communication — and makes it simpler, more pleasant, and more productive.”
We all know that communication is very hard. When teams create together, the hardest job is sharing ideas and knowledge effectively and in a timely fashion. Poor communication is often responsible for work duplication and sub-optimal implementations. Developers have been early adopters of team chat because they understand the importance of fast and easy communication, and know that chat is much better than many alternatives. Still, even within Slack or Hipchat, communicating about code remains complicated and tedious, requiring many steps in order to provide context and relevance.
Talking about code using today’s team chat solutions is hard. Cutting and pasting code snippets into another app causes loss of context, so in order to discuss code you need to add context back into the conversation, like file name, version, repository, etc. We counted the steps required to ask a question today, and it’s about 16. Here is an example:
Imagine a developer trying to understand a given function. With today’s tools, she would have to copy the code, switch over to the team chat app, choose the right channel, paste the code in quotes, describe the code’s repository and file, then the line number within the file, and further, to find out who might know the answer, go to git, do a git blame, and back to chat app to direct message the right teammate. Exhausting…
Further, when you resolve the issue at hand, or get the answer to a question, where does it live? It will flow downstream in your team chat channel probably not to be seen again, and it’s highly unlikely that it will contribute to team or company knowledge because other developers will not know what to look for. It will just be lost, because it’s divorced from the code, and there is nothing that points to its existence.
Using search within team chat to find answers to code related issues is often slow and frustrating. First of all, it’s hard to know what to search for. More important, the loss of context that we described with respect to the process of asking a question extends to the process of finding an answer.
As stated by Ariel Norling, team chat user, “Slack relies way too much on keyword search of previous messages and visual search of documents for it to be helpful for us locating resources that we shared with one another. Slack’s mixing together documents from the channels was cluttering and mostly contextless.”
In addition, in order to focus and concentrate on solving programming problems and come up with creative and elegant solutions during crunch time, coders need to only talk about code and block the noise. You can always just turn off notifications and reduce distractions, …but then, how will you collaborate with the people with whom you need to talk?
Developers generally care about how their time is spent, who they work with, and what they are working on. It’s not only about working on something that matters, but feeling connected, having a common vision and purpose, and eliminating distractions.
According to a survey by CIO Magazine (August 2016), 85% of developers said that working on an interesting project is more important to them than money. 40% said they would rather work from home. Only 17% thought working for a big company was a primary consideration, and only 9% of them have learned Java because it is considered too corporate and boring. It follows that working on stuff that is not interesting rubs developers the wrong way.
Things that feel inefficient, redundant, wasteful and self-evident are among the elements that make working as a team frustrating at times. Very often, the combination of tight schedules and poor communication leads to unhappiness in the work environment. It also tends to produce technical debt.
John Mueller writes in Smartbear (September 2012) that “A lack of communication at some level kills most development efforts. The failure to communicate may be one of misunderstanding or a lack of involvement, but good communication is an important part of the application development process. Developers must communicate with each other as well as with the various stakeholders affected by that application.”
According to an article by Laurence Bradford in Forbes Magazine (August 2017) entitled “What Developers Hate In The Workplace — And How To Fix It” developers find that Constant Communication = Constant Interruption. The article presents the views of Greg Warden, VP of Engineering at DigitalOcean. According to Warden, “developers like blocks of uninterrupted time so they can focus on their work and get in the zone. Nothing destroys that concentration faster than the constant pinging of a message every five seconds,” he says. “I think things like Slack or Hipchat kind of help, but they can cause problems themselves,” says Warden. “It’s too easy to become distracted because, maybe you’re trying to be a good partner to everybody that is dependent upon you, or maybe it’s too easy to be involved in every conversation that’s going on.”
Warden understands that team chat as it currently exists suffers from weaknesses that make developers waste time. The second issue, he says, is that team chat can make it easy to lose track of information: “So you go, ‘oh I remember somebody said something,’ but you don’t remember what channel it was said in or who said it or how long ago, search kind of work but not really well, so you spend lots of time looking for that thing.”
Part of the problem is the proliferation of apps that require switching context when you use them, including team chat. Many users are experiencing app fatigue. Stories of app fatigue abound today. A Fortune Magazine article (September, 2017) confirms that “The average business professional uses 9.4 apps at work. IT workers, have it worse … they use 10.4 apps, on average.” A survey was conducted to dig deeper.
Fortune continues, “Nearly half of the survey’s respondents said they use apps that were not sanctioned by the IT department… the survey found that 351 out of 881 respondents, or 40%, said it took more than five minutes to find an early draft of a project they worked on. And, 120 (14%) said it took much longer than that.”
Consolidation of all notifications through integrations into a team chat channel, where context is also lost, is not really a solution. As explained byAlan Lepofsky, principal analyst with Constellation Research “While people say they would prefer to have all of their applications in one window, they may not realize that could lead to even more information overload than switching between applications. It’s not the single window that is the magic, it’s the context and the ability to filter and focus on the right information at the right time that leads to improvements.”
If this context problem is to be solved, team chat for software developers needs to be both persistent and get “anchored” to the code itself.
Team Chat today is just not designed to talk about code. Because there is so much friction in initiating these conversations, they just don’t happen that often. Because developers — especially new team members and remote coders — communicate less than they should, they make decisions on their own that may not lead to the best design or implementation. By the time the team gets together to review the code and decide if it works as intended, some compromises must be accepted in order to meet the schedule. Frequently a tradeoff needs to be made between accepting unwanted technical debt or not completing the work on time. Neither solution is particularly appealing, yet development teams are forced to make these decisions every week.
As shown above, the are many the deficiencies in the use of of team chat for development teams. We believe the solution lies in tying together team chat capabilities with code in context, by integrating team chat into an IDE. In order to save the knowledge for future use, conversations must become persistent in context so that they become useful not just once but many times. At CodeStream we are working on addressing these issues.
Our team at CodeStream has made a career out of applying the power of real-time communication to different environments and use cases. We launched the first social news feed in a social network (Multiply.com) and were the first to treat tasks and calendar entries as first class objects in team chat. We pioneered numerous innovations in real-time communication and are now focused on bringing those benefits to the world of software development.
Please share your thoughts and feedback @teamcodestream.
CodeStream helps development teams discuss, review and understand code. CodeStream links comments and issues directly to the code blocks they refer to, making them instantly available to everyone on the team.