Software delivery teams must invest heavily in making their team and organization more effective. Time spent building tools, documentation, and collaborating with others is essential to significant future growth of the organizations. The team must focus on a balance of areas in writing the software, making it easily maintainable, building security in from the beginning, and delivering quality products that other teams can build on and customers love.
As we are working on new products, tools, utilities, and various projects there are design considerations we must build into our projects and utilities. Consider every project and utility as something that should be modular, extendable, and general. Oftentimes API services, systems, and tools are written in ways that are overly specific, constrained, tied to only one third party vendor and in general tend to be one time fixes for a problem. As a growing organization we must increase our mindfulness that: We are highly likely to run into the same problems over and over again, tools that we build for ourselves can be leverageable by other teams, and there is now a minimum bar of quality required for any new project before other software teams can leverage those tools. If a team is expected to write tools or plugins or interact with an external API those tools/services need a minimum level of documentation for teams to dig into before bothering the authoring team. Services must expose metadata about how to consume service methods and provide code examples via tests, example projects, or scaffolding utilities. Teams must get into the habit of evaluating their own projects as one would adopt a new tool with fresh eyes and attempt to go through the pain of setting up something from scratch and little knowledge of internal systems. While it can be tempting to default to “Well its always been like this” we need to eject that type of mantra and focus on building tooling that we would enjoy using ourselves. When opening up a project the first thought is, “This is more painful than it should be…” is a prime area to create value and eliminate the gaps caused by inefficient, ineffective, or lacking tools/processes to create value. Once those tools are created it is our duty to share and evangelize their adoption by other teams within and even outside the organization.
Due to the nature of software development there is a tendency to exclaim “READ THE DOCS” to explain that teams should do their research or be aware of the infinite ways to fail on a project. Tools that demand intricate configuration are tools that will cause software teams to consistently cause defects and bugs in their systems. Instead of allowing these bugs and issues to happen teams must exhort the importance of creating frameworks, modules, packages, and tools that push teams into the pit of success first. The sooner that we can adopt these practices in the development of our systems the sooner that future projects can have the inherit qualities of security, robustness, and eliminate a swath of bugs that newcomers will inadvertently cause and/or discover again when learning about the technology they are forced to work with. Once tools are created they need to be marketed, shared, and evangelized by the teams that made them.
Every role in the organization has an insight and an area they excel in and can help us make better products. While they all have different areas of responsibility and ideas of what adds value collaborating across boundaries will help us find gaps more easily. As software developers push out their code they should be stewards of the mission of Operations. Systems fail constantly and for many reasons and they are not always due to changes to the software itself. Software delivery teams can eliminate or minimize their impact by making their systems easily maintainable, observable, and assessable so that Operations can dig in when necessary and track down issues without wasting time. All other departments can be just as helpful and provide excellent feedback that can make all of our systems and tools better to work with and drive future value for the organization. Collaborating with others allows us to find the sharp edges and begin to work on improving or eliminating those from our systems. We can also grow to learn more about the other domains that our colleagues are experts in and improve our own knowledge of the overarching business domain.
Identify the sharp edges, build and share tools with smart defaults minimizing the required knowledge of future teams, and collaborate as much as possible with others.