Over time, the architectural assumptions underpinning a software application may diverge further and further from that application's product requirements. When this happens, engineers are faced with a choice: soldier on with the existing architecture, accepting maintainability and performance issues, or take a step back and consider a different approach.
At Slack, we recently rethought one of the core assumptions underlying our architecture: that all activity occurs within a specific workspace. When Slack launched in 2013, each workspace was a closed system representing a single customer and containing users, channels, messages and files. With our enterprise solution—launched in 2017—this assumption was weakened to allow bundling multiple workspaces under a single organization, but it still held at a high level. As usage grew, we began to run up against the limits of this workspace-centric architecture, which led to frustrating context switching, duplicate API calls and consistency bugs.
As such, we decided to take a step back and ask: what would happen if users could view all their channels, messages, files, etc (within a single enterprise) in one place? With this, the Unified Grid project was born.
But while we strongly believed that Unified Grid was a superior architecture and product experience, getting there was no small feat. This presentation will describe the evolution of Slack's architecture and how it motivated Unified Grid, as well as the tactics we used to go from prototype to production.
Interview:
What is the focus of your work?
My work at Slack focuses on greenfield projects which do not yet have dedicated ownership. I see my role as growing these projects to a point where they can be handed off to a dedicated team via prototyping and working cross-functionally to establish product direction. Some projects I have worked on are Unified Grid (this talk) and Salesforce channels.
What’s the motivation for your talk?
My talk is motivated by a desire to share the inside scoop regarding one of the most ambitious projects Slack has undertaken, and certainly the most ambitious project I've been a part of. People say that engineers should rarely, or even never, attempt huge architectural overhauls—well, this is one example where we tried it and it worked. I think that's interesting and that there may be some lessons that are more widely applicable.
Who is your talk for?
Software practitioners who work with large, legacy software applications and are considering how best to graft a legacy architecture onto evolving product needs.
What do you want someone to walk away with from your presentation?
I'd love for attendees to come away from my presentation feeling empowered to dream big with respect to the changes they might make to a legacy software application. Simultaneously, I'd like them to be encouraged that real change is possible using the concrete tactics outlined in my talk.
What do you think is the next big disruption in software?
While generative AI has already changed how developers write software, it hasn't made large inroads at more established organizations (at least, not that I'm aware of) partly because of its difficulty in handling idiosyncratic legacy codebases. I think that's going to change.
Speaker
Ian Hoffman
Staff Software Engineer @Slack, Previously @Chairish
Ian is a Staff Engineer at Slack, a Salesforce Company, where his focuses include greenfield projects and mentorship. Priorly he was an engineer at Chairish.
Find Ian Hoffman at:
Date
Monday Nov 18 / 01:35PM PST ( 50 minutes )
Location
Ballroom A
