Gresham’s law and Slack

“Bad money drives out good.”

slack-1024x1024When is the last time you spoke with your fellow developer? I mean actually spoke? Or was it just over Slack?

I like really Slack, Flowdock, Hipchat and the like. I couldn’t do my job without them. But as with Gresham’s law, bad communication is driving out good.

It’s become clear to me over the last few years that Slack  — and I use Slack to represent all of its kind  — is displacing all other forms of software engineering communication, to the detriment of our work and the quality of our designs. And like bad money driving out good, no one person is responsible — it’s an outcome of many small behaviours with everyone arriving at the same place. It means no phone and no e-mails, and fewer design documents. And it’s making it culturally unacceptable within teams to communicate any other way.

All of the cost, but what of the benefits?

If Slack is all the team uses, why does it matter?

With it always on, it can be difficult to focus. People interrupt each other on Slack at a rate they never would in real life. Well, turn it off, you say! In reality it’s difficult to go offline, as not being on Slack makes you feel completely unavailable to the rest of the team. If no other means of communication is acceptable, what choice do you have?

Decisions are sometimes made on Slack without all the right people being involved. Important questions that would be better in handled in person or — wait for it — by email, suffer from poor answers. I’ve actually seen teams try to design complex systems solely over Flowdock, and the results have not been good. Perhaps others have seen successes, I rarely have.

Contrary to conventional wisdom tools like Slack suffer from a latency problem, not a bandwidth problem. How can the modern developer consider sitting at the keyboard, staring at Bob is typing…. for 10 seconds between each exchange, an efficient method of communication?

In other words we’ve got all of the cost of asynchronous communication without almost any of the benefits.

What might be going on

What I think is happening, captured graphically — albeit unscientifically — is shown below.

Photo Jan 31, 1 03 21 PM
One of Slack’s clearest benefits is it makes it obviously easier for groups of people, who are not colocated, to collaborate. In fact, it has actually made companies more open to remote developers — therefore allowing companies to grow their software development teams, since they have access to a larger pool of talent. This is a significant gain, and seems to grow in a linear manner — access to twice the talent pool means potentially twice the engineering team (all else being equal).

However, the power accruing to developers is increasing exponentially by the year, thanks to Moore’s law and cloud computing. This means that the cost of bad design decisions and poor quality work is greater than ever — but one of the biggest  drivers of good design and work is good communication. With Slack becoming the sole way development teams communicate, the benefit of the larger talent pool is being swamped by the cost of much lower quality communication. Effective communication between developers is difficult enough, and Slack’s complete displacement of meetings, emails, and the ‘phone, is making it even harder.

As a result productivity may actually be decreasing drastically past a certain point, when measured in terms of design quality and implementation.

I really like Slack

I really do — modern IM systems are great tools. I find them particularly helpful when debugging an issue with the team, when so much output is text-centric, and referencing precise areas of code during discussions is invaluable. And if you’re in Operations, or work closely with the Operations team, they are of enormous benefit when dealing with outages, where fast, unambiguous sharing of technical detail is paramount.

Slack, Flowdock, and Hipchat, and the rest, have been a huge boon for developers. But as software developers we need to push back on its encroachment on every aspect of team communications. Use the right tool for the right job — get together in front of the whiteboard, pick up the ‘phone, write an e-mail, and write your design documents.

Sometimes Slack will certainly be the best tool. But because successful software development is all about people, getting the communications right is too important to leave to drift.

Leave a Reply

Your email address will not be published. Required fields are marked *