In a recent interview by McKinsey, Twilio’s CEO Jeff Lawson discusses his new book and the engineering culture at the customer engagement platform company. In the interview, Lawson, whose background is in software development, talks about the importance of the “paved path” at Twilio that helps strike a balance between developer autonomy and delivering secure, reliable products. Part of that, the article says, is ensuring developers can pull approved services off the shelf to focus on building “the code that counts” -- the code that customers actually pay for.
The key to paving that path is having a strong strategy around tech stacks – the sets of technologies used by an organization to build web or mobile applications. This is a way to describe the set of programming languages, frameworks, libraries, server-side technologies, UI/UX solutions, and tooling used by developers.
Each layer in that stack quite obviously has a lot of things in it. And each layer may have different stakeholders, tools, and processes used to monitor those components. These tools and processes may work exceptionally well for that team, but when someone else needs to see what’s going on in that layer of the stack that doesn’t “own” that layer, it can be hard to speak the same language.
At StackShare, we pride ourselves on helping CTOs, developers, engineers, and enterprise architects make better and more streamlined technology decisions. We give developers the ability to publicly discover and discuss what the world’s best technology teams are using -- but these tech stacks can become incredibly large and difficult to manage.
Take Uber’s tech stack, for example. The Uber dev team is using more than 50 tools within the stack. Lyft has 64 tools within its tech stack. Zumba, the popular dance workout, has more than 80 tools within its tech stack.
With large teams accessing these tools and individual components, version control can become a nightmare...fast.
How Top Companies Are Currently Managing Tech Stacks
For many years now, version control systems – tools that allow developers to track and manage changes in the source code – have gained traction for the capabilities and benefits they provide in getting everyone on the same page when it comes to source code.
It’s time to bring that same level of capability to monitoring and ensuring visibility into the full tech stack.
Why? Because better visibility into tech stacks allows different stakeholders to continually optimize the different layers and align strategies. Making the information easily accessible saves time finding the best technology to integrate with and makes it more likely that strategy will be pursued. It eases testing, helps developers build more secure products, and accelerates the discovery and remedy of issues when they arise.
There are measures in place at most companies to track and monitor stacks currently, but they have limitations that hold companies back from realizing the full advantages of the tech stack. These tend to drive people outside of the process, which perpetuates more problems.
Not getting the collaboration capabilities via Excel, team members send more emails, and that information isn’t logged, tracked, and documented. Or maybe they don’t even know where to find the documentation because it’s hosted on some obscure SharePoint or Confluence page only known to certain teams. Lacking chat tools in a wiki, team members may use Teams or Slack. Questions posed don’t go to the right people or knowledge imparted is lost when that chat window closes.
So instead of building and testing code, teams spend a lot of time looking for the right information just to get started. Questions like "What version of Node.js should we be on?", "Who is our AWS expert?", "What's the best way to deploy a Kubernetes-based app?" All of these answers get lost in Confluence, Slack/MS Teams, and email threads. For the developers asking these questions, the context switching drags them down.
Because these answers aren't easily accessible, companies end up adopting duplicate technologies across teams, taking on the same internal projects over and over with no standardization, and spending hours if not days trying to find internal experts on specific technologies and implementations.
On average, more than 20 percent of a developer’s time is spent on non-coding activities.
Wikis
This is to say that Excel and wikis are not really good starts – and there are some really good wikis. Wikis can be simple as a web page with open editing capabilities or as super-charged as something like Confluence, which offers advanced collaboration functionality for project documentation and native integration with Jira for agile development and software project management. But depending on what they offer for functionality, using a wiki has drawbacks, including ensuring strong versioning control in less robust tools and a steep learning curve to gain comfort with others.
Spreadsheets
Spreadsheets present similar issues in making sure things are up to date, ensuring versioning control, and easy accessibility. Typically emailed or hosted on perhaps an internal portal, spreadsheets can’t provide reliable data in the anytime or anywhere manner that allows teams to work at the pace they need to. With distributed and remote teams, and many developers pulling the “night shift” to do their best work, lack of easy and reliable access is a problem that can quickly spiral.
Visual Diagrams
Another tool in use is visual diagrams of the stacks. This provides a really great way to onboard engineers to understand the architecture and the systems. But once drawn, the diagrams can be tough to keep up to date and may not be able to be accessed by developers in a way that aligns with their needs.
Now’s the Time to Upgrade Spreadsheets & Wikis
ADRs and Tech Radars have emerged as popular open source tools to help you plan for and document tech stack decisions. However, businesses must take it a step further and have a system of record over time, not just the point-in-time decision-making process.
The best stack tracking tools make it easy to see what is in place across the company and automatically update and notify stakeholders when changes are made to the stack. Private StackShare for Teams allows businesses to get a full picture of their software stacks, track and see changes, and facilitate collaboration using technology that can automatically connect to repositories, pull a complete picture of open source technology use across the enterprise, and allow everyone to see it all in a role-based dashboard.
Anytime a developer merges a pull request that contains stack changes in a connected repository, that change is automatically documented. The dashboard shows alerts anytime a tool is added, removed or a version is changed. You can search across private and public stacks, to speed development while also ensuring secure use of components and tools.
This all eases and encourages collaboration across engineering teams because colleagues can easily identify and ask those who have used specific technologies for advice, while also proactively alerting developers when a specific technology is tagged in their post. And all of it further paves the path for all of the stakeholders around the tech stack.
Private StackShare for Teams is the modern way to track your tech stack, giving you access to the wealth of technical knowledge across your company and drawing technology insights from your Git repos.
Want to know more? Check out Private StackShare on the GitHub Marketplace and sign up for free today.