Overview
Excellent software has been produced by development teams that had total control over what tools they used and also by teams that had their tools mandated by management. On the other hand, poor software has also been delivered by both approaches.
Here are some thoughts to consider as you decide how your tooling choices are made.
Pro’s
Development teams are more autonomous and have more tool choice
- The team becomes more invested in the process of building code.
- The more invested your teams are, the better their product should be.
- This reduces the need for a systems administration team and the number of employees in it.
The teams are less autonomous and have less tool choice
- Fewer tools to rely on for producing output means there is less variance to consider in effort projections
- Fewer pockets of tooling knowledge reduces knowledge fracturing
- Less license sprawl reduces cost
- Teams that use the same tools can cross-pollinate the lessons they learn
Con’s
Development teams are more autonomous and have more tool choice
- Tool sprawl, which leads to consolidated pockets of tool-centric knowledge and devalues remediation groups such as SRE’s.
- Lack of standardization in the development process, which leads to difficult deconstruction when remediation is done by groups not involved with the initial development process.
- An individual developer becomes a chokepoint, should they become unavailable.
The teams are less autonomous and have less tools choice
- There may be better tools to use.
- Your team may feel de-valued and become disinterested
Additional Influencers and Considerations
Who is responsible for the maintenance of the code, the Site Reliability Engineer’s or development team?
The team responsible for the viability of the tools should have influence.
Who pays for the tool and its administrative upkeep?
The group fiscally responsible for the tool should have influence.
How well does a particular tool integrate with your existing tooling ecosystem?
Tools that integrate easier and better should carry more weight than those that don’t.
Does a tool have a killer feature that your team MUST have?
This should be considered and weighted appropriately.
How comfortable are you with staff turnover?
If you have a well-defined requisition that is easily filled, then you’re in a position to accommodate a higher turnover rate than if you are trying to replace a specialist. In other words, let specialists have more influence than less specialized roles.
The easier it is to collect the data required for your quality and delivery KPIs, the less time is spent on normalization; which reduces your data’s time to market.
Normalization efforts are typically a highly manual effort. Reducing the amount of manual intervention increases the accuracy of your governance metrics.
By applying control at the point you perform evaluations, the maximum opportunity is provided for individual tool choice.
A happy developer makes useful software and happy users. We don’t want your engineers feeling like Bill Parcells.
There will be a proper balance of accuracy, time to market, and staffing for your situation.
