Okay, so you're convinced you need a developer tools team, or at least that development tools are important to build.
Now, what kind of tools do you build?
There is no answer that works universally, otherwise you wouldn't really need to build anything. The key is finding what things your team is doing frequently and automating those things, or finding the things the team wants to do, but is unable to do.
One thing we can do is look at some common areas where custom tools are likely to be needed.
Logging
In many places I have worked and many software development shops I have visited, there always were plenty of logs. The problem with logs is they tend to be large, hidden on a server somewhere, and hard to read.
One area of opportunity is a tool to parse and extract important information out of logs and put it in a format that is more digestible to someone troubleshooting a problem or doing analytics. One particular area of interest here is log messages dealing with uncaught exceptions. It is always good to automate a way of reporting on those types of problems.
Applications also often lack the log information for certain important parts of the application or processing that you only find you need once you are running in production. Tools to instrument code and insert logging into your application while it is deployed are very useful and can be a life saver in understanding that error that only happens in production at 3:00 AM.
Most web servers have logs of HTTP requests that come in from users. This information can be very useful in determining how users are actually using your application. Combining this information with session ids and timestamp data from your database, can provide you with exact click flows for users and answer many questions like “how the heck did this data get created?”, or “how are they creating this problem?” Tools to aggregate this data and create representations of the user's actions can be invaluable.
Developer Build and Deploy
Developers build and deploy the application many times a day on average. This is one of the most commonly repeated activities. Yet, I find that in many organizations this is a complex process or takes a very long time.
Consider writing tools to dynamically load parts of your application so that only that part needs to be built. Good candidates here are sections of code that change frequently and are isolated.
Deploying to the web server should be a one button or one command operation. This is often a very “low hanging fruit” that can provide large benefits by saving time.
There are often many areas of the build process itself that can benefit from some tool that will speed it up. Examine your own build and see what is taking the longest amount of time. Is there some way to speed that up by developing a tool, or using your build tool in a better way?
Look carefully at the process developers are using to pull down new code, build code, write code, test code, and check it back in. Look at each step in the process. Try to find areas that are being repeated, which do not need to be repeated over and over. One really good thing to look for is some process that has to be started, followed by a wait, then another thing that has to be done after the wait. When you see this pattern, making the process that has to be done after the wait automatically happens usually has a great return on investment.
Testing
There are huge gains to be made in this area with the proper tools. I have talked several times about the automation frameworks I have built, but there is much more in this area than just that.
Consider the creation of test cases. Where are they stored? How are they written? Closely examining this process normally yields interesting results in finding duplication and wasted effort. Copying and pasting rows from spreadsheets takes time and is inefficient. If you are going to write and maintain manual tests, then having some tools to help you do that can make a big impact.
Testing itself can usually be automated. Take a good look at what you are testing. There are some things that cannot be automated, but usually if you can give something a pass or fail result, it can be automated. My best advice here is to use an automation framework, and build a custom application specific framework on top of it.
Tools to manage where code is deployed and test environments can be very useful depending on the process your organization is using. Take a look at the process involved in determining where features exist in what environments to look for areas of optimization. Take a look at the process of getting code to different test environments.
Development
Many people don't think about the automation of code development, but there are often many areas where tools are useful. Consider some of the commercial tools that automatically refactor code or generate UI's.
The first place I would start here is looking for any code that developers have to write that is boiler plate code. Good examples are code that serializes or deserializes specific objects to or from a location, or any kind of code that is a mimic of some external structure. Often tools can be written to generate code once the pattern is well understood. Code generation tools are extremely useful because they are able to reduce the total amount of code that has to be maintained and they save the time of creating that code.
Unit testing tools or scaffolding can also be useful for setting up basic scenarios or data structures that often have to be set up in many unit or integration level tests. Carefully look at the creation of new unit tests for your code base, and determine where there is common code that is being written to set up data, or mock something out.
Data
There often arises the need to do many things with application data, whether that be transporting it to another environment or obfuscating it to protect sensitive information, or some other purpose.
Look carefully at the things you do with data, or what you would like to be able to do with data from you application. If you have a DBA that is doing lots of “stuff” you can probably find tools to help him do that “stuff” and bring it down to the teams. Relying on DBAs doing “stuff” puts your software development team over a barrel.
Often teams need to transport portions of data from environments to test an issue that is happening in production. There are opportunities to create tools that can move the data and change personal information to protect that data.
The process of altering the database structure is also a good one to consider. How do developers make changes to the database structure? Is it a long and lengthy process requiring many steps?
Parting words
These are just a few of the areas you should look at when thinking about what kind of tools can be created to help automate your processes. The key here is to look for the processes that are being done and to try and find ways to eliminate or automate steps. It is not always cost effective to build a tool. It depends on the size of the organization, the effort in building the tool, and frequency of use. But I have found that there are many opportunities to improve efficiency by automating that are not apparent until you look.