The Developer Battle Against Software System Complexities
The Uphill Grind Facing Software Developers for Tech Stack Control
Modern software systems look different from even just a few years ago. We used to build apps within physical servers, and now we’re dealing with containers, Kubernetes orchestration, distributed cloud environments, and more.
With so many tooling options, software development is becoming increasingly complex and bulky. We’re getting into the issue of including too many tools in our development life cycles, often leading to the waste of time and money.
Our Software Development Landscape
Not to mention all of the tooling needed to build and maintain it including scripts, build system, source control, and test automation tools. Although this is the widely accepted software development standard, these complexities are a strain on resources and include developer satisfaction.
With every step of the SDLC comes countless tooling solutions that seek to make it easier. Amazon Web Services, Microsoft Azure, and Google Cloud offer about 200 unique services each. And this isn’t even counting all of the smaller vendor options out there, as the development world’s interest in using startup tech continues to grow.
The Demand Driving the Complexities
With so much on our plates, developers generally tend to focus on getting tasks done on deadlines, rather than thinking through smart tooling decisions that can benefit the whole business and its customers.
The average developer is pulled between project planning, debugging, integration between technologies, security challenges, and operational challenges. This divides their time as well, with on average only 32% of their time actually spent writing or improving code, while the rest of it goes towards meetings, operations, code maintenance, and testing, among other categories.
Because developers’ responsibilities cover so many different areas, they often find it easiest to put “bandaids” on small problems. These quick fixes often come in the form of downloading or purchasing a tool that solves the specific pain point in question. This cycle makes the entire SDLC become very bulky and overly complex from tech debt.
Related Article: What Is Tech Debt? A Guide to Understanding Technical Debt & How To Address It
Sematext used a great analogy for overly-complex and bulky developer toolkits:
"If you were a carpenter, you wouldn’t carry around a dump truck’s worth of tools. If you did, you’d spend so much time searching for and switching between different tools that you’d neglect your core job duty. You’d instead want to stick to the essential set of tools that you can fit in a toolbox or two in order to keep things simple. Doing the same with your DevOps toolset is crucial for the same reason."
Developers are already expected to stay on top of new technologies as part of their core job. An overabundance of new technologies wastes developer time. Every time a new tool is added, it comes with a learning curve.
Regain Tech Stack Control without Missing Great Tools
Although over-tooling causes issues, there are so many great tools out there. Here are the best ways to balance the outstanding resources available to development teams without creating unnecessary complexity.
To cut back on complexity, it’s important to know which teams are using which tools. By knowing who’s using what, it’s easier to cut down on tool redundancy. If two teams are using different tools for the same process, for instance, one of these options can be removed to simplify the business’s toolkit as a whole.
Start with gaining visibility over your organization’s development groups. Private StackShare for Teams’ dashboard shows all open source tech and the people using it in a single pane of glass.
Bring developer visibility to interesting technology projects and open roles with Private StackShare for Teams, allowing more internal mobility through a well-streamlined toolkit. Internal mobility leads to better talent retention and synergy between development groups.
2. Broad Category Approach to Problem Solving
Revising the process of choosing tools in the first place also helps to reduce complexity. Instead of reactively choosing tools to solve specific issues, take a broad category approach and look for solutions that solve the immediate need but also a broader need. Looking at the broader category of tool solutions keeps your toolkit more streamlined because a single tool can be used to solve various different issues.
Private StackShare for Teams allows developers to understand what’s inside their DevOps toolkit, how it’s being used, and how the SDLC can be streamlined based on the team’s needs, including creating a broad category approach for problem solving. By saving the developers’ time in this process of streamlining tools, PSS allows them to focus on what they do best: writing code.
3. Researched Decisions for Tooling
Setting up a formal process for deciding on tools is another great way to cut back on complexity. Some organizations even use an internal platform team to vet tools, build templates, and plot paths into production. Private StackShare for Teams includes visibility of tool adoption stages, allowing your whole team to work together and make methodical choices on tools.
StackShare’s community of developers, CIOs, and other professionals serves as a great resource for learning more about great tool choices.
Focus on Developers, as well as Technology
Ultimately, a tool is only as skilled as the people using it. This is the concept of mechanical sympathy - when you have a solid understanding of how to use your tool or system best. The same can be true for developers. The benefit and the burden of developers and dev teams are finding where their expertise gives most value and where it is being wasted.
The question is whether your business’s toolkit is best helping the organization or using up valuable time by requiring developers to learn too many tools. We believe that the best foundation for starting to answer this question is the visibility of your toolkits, and we’re here to help you begin with tech stack intelligence.