The Downside of Tool Autonomy This editorial was originally published on January 31, 2019. It is being re-run as Steve is on sabbatical. I am a big believer in letting teams of people work in a way that allows them some autonomy to solve a problem. I think this is especially important in the software world, where developers need to experiment and learn from the new ideas that they investigate. They need to be able to try new techniques, technologies, and platforms. Yes, that includes NoSQL data stores. At the same time, this can lead to developers becoming captivated by new tools and techniques, all of which are good for advancing skills and code maturity, but can also lead to a very disparate environment where there are no best of breed solutions, or no standards for writing features. As the number of developers grow, this also raises the bar for each individual to know and understand more languages or technologies. While I do think it's easy to pick up logic and syntax, when writing production code, we want to ensure we're optimizing the way we work. The way in which we might write some code when we start with a new API, SDK, language, etc. is often not the way we'd write that code after a year or experience. At least, I hope it's not the same way. There are nuances, tips, and tricks in how to better structure code that we learn as our experience grows. When I was at the Redgate Software office last year, I noticed that there was a short article posted on our internal blog. This noted that there is a set list of tools and technologies to use when building our products. This isn't intended to be a long term immutable list, and the post noted that other choices are possible, but we want to avoid an unending growing list of tools when we have identified there is a good tool in a space. There is an approval process to propose and new tool and explain why it really is needed. At Redgate, we're pretty flexible and open, so I'm sure this isn't a tough process. However it does prevent every developer from implementing their special little code into a project. We've had people use various different data stores, different types of web technologies, and it becomes a maintenance issue over time. Even the VB.NET component we used for years at SQLServerCentral caused headaches as there wasn't any experience in the company in this language. I think it's worth having some light overview that ensures an organization isn't adding technology just for the sake of making one or two developers happy. There is a finite amount of time to spend learning and growing, and while it's important that technology workers do this, we also want to developer more experience and expertise in a few areas. Limiting tools and technologies helps preserve a balance that allows for growth, but ensures the expansion isn't unchecked. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums | 
