Choosing Tooling and Technology for Application Development

The ZoomInfo application team works on a lot of different projects with different requirements and priorities. Completing these projects efficiently requires employing a lot of different tools and technology, but it also sometimes requires allowing yourself to make decisions relatively quickly and implement them knowing that they may need to be modified or even reversed later.

This flexibility is important as it allows forward progress and also helps to provide data needed for evaluation of the selected tools. Some of the factors ZoomInfo takes into account include project priorities, team expertise, and the technology and tooling already in place.

Considering Priorities

One key to managing this process is having a good idea of the priorities of a project. There may be three or four viable tooling options for a particular task but each of them will likely have different strengths and weaknesses. If one option provides faster application development and another provides better performance in the end result, which option is better for the project? It depends on whether getting something – anything – out the door or having a product that processes queries quickly is a bigger priority. This may not be a binary choice; evaluation of the choices might involve whether the option that provides faster application development also provides performance that’s good enough or if the option that provides better performance can be developed quickly enough to meet the related business needs. In this type of scenario, you may wind up going with a third option that slows down application development slightly compare to the fastest option and that isn’t as performant as the best performing option but that does both within the parameters set for the project. If you move to a new project with different priorities or the priorities of the existing project change, the choice you make may be different even though the available tools didn’t magically change their qualities.

ZoomInfo definitely considers the project priority when considering which tools to use; on a recent project the backend database was selected in part based on query performance being prioritized over other factors; the solution they settled on has the needed performance level at the expense of not being quite as scalable as some other options. If the priority had been set differently or if it changes in the future (or if the scalability of the current solution ever falls below a “good enough” threshold) then this decision would be revisited and the database solution used likely changed.

Considering Team Expertise And Existing Tooling

Another consideration might be the expertise and experience of the developers working on a project. If five of the six members of a project team have extensive experience with a particular database, it may make sense to use that database (provided it does most or all of the things needed to a sufficient level) even if there might be others out there that more closely match the exact requirements of the project. Similarly, if all of the other projects of a particular team uses a particular tool to perform a task that a new project also needs to perform, it is likely more efficient to use that tool as well if it works within the project framework. If there’s a staff rotation a few weeks into the project and the new team members have absolutely no experience with the tool that all of the previous folks were experts in, you may need to revisit the decision and evaluate whether it’s easier to help the new folks get up to speed on the tool or change the tool to an equivalent one that they already know how to use.

It may also be policy or considered good practice not to expand the development tool set unless an existing tool does not meet a project requirement. This may go hand-in-hand with the consideration of team experience above; if there are four different databases already in use at a company then folks developing data-driven applications for that company will likely already be familiar with these databases and have some experience using them. It also means that there’s a built-in support mechanism at the company; if the folks using the tool run into any problems they have difficulty solving there are other people around who might be able to help and keep the project moving smoothly. It can also be more efficient from a cost perspective, allowing funds that might be spent for commercial tooling or support contracts on other things.

ZoomInfo does not have a formal policy about using existing tooling and technology, but some application projects use this to limit options in a first pass. This helps to timebox the tool selection process since some types of tools may have dozens or hundreds or even thousands of options out there. If none of the existing tools seem to meet the project requirements then a wider net is cast. For example, when a recent project wanted to try a NoSQL database option, they turned to MongoDB rather than doing a survey of the many NoSQL options out there to determine the absolute best option for the project. ZoomInfo already uses MongoDB on other projects and our developers are familiar with its use. When MongoDB didn’t quite fit the requirements and priorities of the project, they looked to other databases already in use at ZoomInfo next and switched to a SQL database that better meets the project’s highest priority. The team is open to possibly changing to a different database, perhaps one not already in use at ZoomInfo, if the requirements or priorities change in the future and the current choice no longer meets the needs of the project.

Final Thoughts

There are many different ways teams select the right tooling for their projects. The ZoomInfo application team looks at the requirements and priorities of each project and tries options that seem to fit those priorities. If they don’t, they quickly move on to a different choice and remain open to future changes as projects and priorities change. They also give some priority to tools that are already used somewhere within the application development ecosystem, looking to leverage existing expertise when possible.