The Downside of Tool Autonomy

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

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.