In this post, I wanted to reflect upon a common challenge for small IT businesses as they mature. In your enterprise, you can observe healthy growth of your software teams in terms of project execution and code quality. In the ideal, we should further support our software teams by encouraging software teams to share code. Right? How hard can that be?
Benefits of shared code culture
As we start a new project, software teams should have the ability to kick-start their progress by leveraging shared building blocks or code modules. In 2021, how many teams start building their projects by creating a brand-new framework to manage a web server and http calls? That’s ridiculous. In the more common case, software teams leverage established and trusted frameworks for their application server. (i.e., ruby on rails, asp.net core, NodeJS, Java EE, etc.) Of course, IT organizations can further extend this idea.
If software teams had shared code modules and frameworks, multiple teams can contribute to new features and extensions of the shared module. Further, a culture of “internal open source” creates opportunities for teams to collaborate and communicate across silos and project boundaries. I know I value getting to learn new patterns and tricks by pairing with other software leaders.
Making an “internal open source” movement
We can learn lots of lessons from open source in the wild. What are your favorite open-source projects? For the sake of discussion, I’m going to list a few popular open-source frameworks: Ruby on rails, Kubernetes, PrimeNG, and React.
For each project, what are some of the common challenges that needed to be solved to create impact and grow community?
After reflecting on the following blog posts, I wanted to explore some of the common challenges faced by enterprises trying to grow an effective knowledge sharing and code sharing strategy.
Challenges of Growing “Shared Code” Culture in the Enterprise
Community engagement plan: All great projects start with great people. Why did Ruby on Rails (RoR) become a super influential open-source project? David Heinemeier Hansson, the creator of Ruby on Rails, executed with intentional leadership. I love how he blended the best of trends in Ruby, pragmatic programming, test automation, and applied community engagement practices. While the RoR fostered an open community for contribution, the RoR community fostered clear opinions of quality code. Like a good technical leader, David helped foster quality in the project through good peer reviews and clarifying quality standards. For many open-source projects, it’s common to have a documented plan, code of conduct and capacity for community engagement. Community engagement strategies set clear expectations regarding the level of support, ways to request bug fixes, and ways to contribute effectively. All the work shouldn’t fall on the founder of the open-source project.
Clear documentation with examples: All my favorite open-source libraries have the “heart of a teacher” mindset. In addition to having high quality functional code, the shared code project should have clear documentation, example projects, and code samples.
Cross-team communication and knowledge sharing: I believe that open-source projects thrive in the open internet because of community. To foster community, community leaders s effective channels for engaging followers. Let’s reflect on the React community for a second. At ReactJS.org, you can review an effective blog, roadmap, and getting started tutorials. On the open internet, you can find community resources on Twitter, Gitter, YouTube or LinkedIn. To have your project discovered, there’s effort to market to developers. In enterprise perspective, do you have a platform to share lessons learned across projects? (i.e., internal blogs, video sharing or wikis) If something goes well on a project, how do you celebrate that win across the whole organization?
Define clear targets: It’s very easy for upper management to demand code sharing across projects. As software engineers design micro-services or classes, we value the single responsibility principle (SRP). I believe that great open-source projects have a strong focus or mission statement. If a framework claims to do everything for you, it’s harder to succeed. In the enterprise, it’s easier to gain shared alignment and unity around small topics. With that in mind, shared code authors should consider designing their libraries for a tight and focused mission. With that in mind, enterprise leaders should set intentional missions or quests for their teams to achieve.
Quality: As leaders, we want our projects to delight our clients. We want our clients to experience our projects with a feeling of “wow!” In other words, we want our projects exceeding the expectations of requirements. I think many open-source projects become popular because developers want to feel more productive and desire to increase time to market on “wow” user experiences. In agile culture, we know that change is the only constant. In the ideal, the code base should have patterns for test automation to help earn trust of their user community. While code quality is well documented in books and blogs, it’s not a trivial challenge for a project team.
Adjust capacity planning: This quote is probably true for many organizations: “Keeping in mind that at any given time an engineering organization is probably overloaded and at capacity just getting stuff done, there’s not a lot of room to just overlay new goals.” If enterprises desire a shared code culture, we must acknowledge that leadership needs to provide budget, schedule, SMART goals, and alignment. A project has very natural forces that encourage teams to work in silos. If we reflect upon all the leadership challenges mentioned in this blog post, we must acknowledge refinements to project scope and the capacity of “shared code” modules. I’ve heard that the VS code team reserves capacity every sprint to maximize community engagement.
In our next post, we’ll review some cultural solutions for these challenges. Please know that we love to hear from our readers. If you have tips or experiences with growing internal open source culture, please share them in the comments.