Over the past few years, Springthrough has attempted to find and standardize on one instant message platform. We wanted to find a low-friction, easy to use, all-inclusive tool to aid in day-to-day communication. While a noble endeavor, such a tool does not exist. Some of the tools that Springthrough has tried in the past are as follows:

• HipChat (an Atlassian product)
• Lync (a Microsoft product)
• Google Chat/Hangouts (a Google product)
• Skype (a Microsoft product)
• Outlook (a Microsoft product)

While nearly all of these tools come with features to increase team productivity and efficiency, they all fell short in some area of core communication for our Development team. Over time, small factions of developers would begin using different tools to communicate about clients, project status, etc. As you can imagine, we ended up with a disjointed and fragmented collection of communication data. If I needed to reference conversations about a certain client or business matter, an arduous search endeavor lay ahead to locate those conversations across several tools.

In an effort to solve that problem, the Development team decided that Lync should be the sanctioned chat client for Springthrough employees. Unfortunately, we quickly learned that Lync lacked features and experiences depending on the platform you use (Mac, Windows, Android, etc). Few people actually ended up using that tool, rendering it useless.

Emergence of Slack

In late 2014 and early 2015, a small group of developers started using Slack as their method of communication. At that point in time, it was just another chat platform. Unlike some of the other tools, it had some distinct features that were enticing to the engineering mindset.

Slack is somewhat unique in that it first asks you to create a top-level “team” which is fully separate from any other team on the planet. Within a team, you can create different chat rooms called “channels”. You can invite other members of your team to join a channel, or you can lock it down to only certain members. Of course, direct-message functionality is also available. Most notably for our Development team, Slack offers something they call “Integrations”. You can post messages directly to chat channels programmatically, from virtually any platform.

To put that feature into practice, a couple of developers wrote custom integrations with Slack. While not entirely useful, they quickly showed how powerful Slack can be. For example, one of the first integrations was that of a way to post images based on keywords into a chat conversation. Another integration injected funny Chuck Norris quotes if you mentioned his name in a chat session. The ability to push/pull data to and from the platform ultimately fueled our effort to use Slack in a more official capacity at Springthrough.

Springthrough's Official Use of Slack

In 2015, we created an official Springthrough Slack team. Over the next few months, other developers and employees at Springthrough slowly started to use the platform. The more users we added, the more we noticed that Slack overcame a big challenge with the other platforms we tried. It works well across a variety of platforms. As of this writing, Slack is supported on the following platforms:

• Browser (modern browsers such as Edge, Chrome, Firefox)
• Windows
• Mac
• Android
• iOS

The timing of this adoption coincided with changes within the Development team, specifically source control and continuous integration processes. Ultimately, we ended up with powerful integrations that impact our day-to-day development work.

TFS, GIT, CI, Logging and Slack

The Springthrough development team uses TFS (Team Foundation Server), a Microsoft source code repository, to version and save all source code. TFS uses its own brand of source control called TFVC (Team Foundation Version Control). This had served Springthrough well and was tightly integrated with our development tool, Visual Studio.

Alongside changes in chat platforms, a paradigm-shift of development methodology took place. With more effort placed on an agile-style process, TFVC lacked certain tools - most notably, the concept of “pull requests”. A pull request is simply a mechanism to enable peer-review of code before it is checked into the source control repository.

In 2015, TFS had an important milestone update, which allowed for a second source code repository option: GIT. GIT is another source control and repository technology that works similar to TFVC with some important differences. Most importantly, GIT allows for an easy way to do “pull requests.” Shortly after this update, Springthrough began using GIT as the de facto source control mechanism for new/past projects.

Another large update to TFS in 2015 was that of a complete overhaul of its CI (Continuous Integration) system. What is CI? CI, on a basic level, is the automation of source code compilation based on certain events. For example, someone submits new code to the repository, thus triggering the server to build the source code.

So what does all this have to do with Slack? As part of the 2015 updates to TFS, the ability to use Integrations with Slack becomes standard. This means, that when someone checks in code to the source control repository, we could automatically send a system message to a Slack chat channel. Likewise, if someone checked in code and requested a “pull request”, that notification too, could be sent to a Slack chat channel. And, finally, CI events can also be sent to a chat channel: most notably, if a build fails and/or succeeds.

Example of a Pull Request notification in one of our Slack channels. 

Example of a Build Notification in one of our Slack channels.

As of now, most active projects use TFS integrations into Slack and rely on it for the following:

• Build events
• Code check-ins
• Pull request submissions and updates

Developers at Springthrough are continuing the process of integrating other aspects of the development process within Slack. One of the challenges for any development team is a common way of logging events and messages of software that is built for clients. In 2016, we started to use Slack to display log events, warnings, and errors from deployed software. This allows yet another way for us to better serve/provide value to our customers and to react quickly when critical bugs arise.

Slack Today

Project teams at Springthrough now use Slack to quickly chat about development work, updates, and messages coming from TFS about builds and pull requests. The development team improved its velocity and efficiency thanks to the new features. No longer does Springthrough consider the chat platform THE way to communicate, rather one way to tie in different processes within the organization to surface information in a common way. It’s important to note that Springthrough still uses other technologies to communicate within and outside of the organization. Slack is just one piece of the communication stack that Springthrough relies on. For example, the following technologies make up our communication ecosystem:

• Office 365 – Email/Scheduling.
• GoTo Meeting – Audio/Video conferencing.
• Slack – Instant messaging, development event integrations, project discussion, general discussion.

Challenges and Caveats

Slack is a wonderful tool and contributed to positive changes in the development team, but that isn’t to say the platform is without potential pitfalls. As the numbers of projects grow within Slack, so does the number of chat channels. During the day, it can seem like there are quite a few notifications flying back and forth within the tool. This can be distracting. What’s more is that within general discussion channels, the urge to respond quickly can be a hurdle for some. In an environment like Springthrough where interpersonal cooperation and relationships are paramount, the urge to participate in discussion can be high.

Secondly, as other organizations explore and ultimately adopt tools like Slack, the danger is that every communication issue is a nail and Slack is the hammer. Real-time communication is great and can definitely be useful, however it can also become a distraction and detraction from getting actual work done. Careful thought needs to go into the intended application of tools like Slack. Some questions to ask could be:

• Do we have a need for instant messaging? Is timely communication necessary?
• Do we need to integrate this communication (and data) with other system in the organization?
• Do we allow non-business communication to happen within the tool? If so, what’s the cost to productivity?
• Do we need cross-device compatibility for near-real time communication?
• Do we require data security regulatory restrictions (HIPPA, Government, etc.)?
• Do we require a full history of communication within the team? (Slack provides this within certain paid subscriptions)

As technology progresses and systems are offering more and more points of integration, tools like Slack will undoubtedly shoot on the radar for IT and business leaders alike. Inc. Magazine recognized Slack their company of the year at the start of 2016. The next 5 to 10 years will see more integration and more sharing of data in the name of greater (read: better) communication. Slack just may be the tool that leads that charge.