I recently attended the Velocity Conference and DevOps Days in the Bay Area. While I usually pride myself in being “in the know” of what is available and possible. It never fails that every time I do a search on some aspect of the development process, or attend events like these, I’m shocked to discover at least three new tools I have not heard of. “What’s this… yet another functional testing tool? Let me guess, you do performance monitoring? System alerts by carrier pigeon? Cool, configuration management that also repairs your TV.”  There are so many tools and their competitive advantages are usually so specific you really have to work for the company to understand them. So how do you possibly make sense of this space? And what is next?

The problem is, I like almost all of these tools! I genuinely get excited when I test each one. But unfortunately the vast majority of them will not survive. However there is a benefit of so many existing and new tools coming into the market, when observed holistically, you can see the trends of the market at large. Thus the trends in development process improvement. It’s a barometer of where software development is going.

The reason the space is getting so crowded is because we all believe software is eating the world, and developers are the masters. If you are an entrepreneur and do simple math on 20 million professional developers, the outcome looks good. But when you get into the details of the number of tools, the way development teams pick tools, and the shift of power to front-end developers. It gets sticky.

Focus on the categories of tools

The key is, don’t get caught up with one tool, rather the category of tools. There are several listings of categories out there, but LeanStack.io is my favorite. If you are just trying to learn the market, always keep in mind how fast it’s changing. While the general categories of tools remain the same, the tools themselves are in flux. Just pick a vendor site and watch it over a six-month period. My guess is you will encounter four different versions of messaging and value propositions. That is because they, like you, don’t even fully understand the market. Part of the problem is we are all guilty of getting caught up in the terminology, over the solution. The term DevOps is guilty of this as well, but heaven forbid they start talking about the Internet of Things (IoT) or NoOps.

Are they all going the same direction?

What has been very interesting is that many tools in the market are actually converging on the same point in space and time. For example, you would not think that a cloud IDE is in the same ballpark as a configuration management tool, but when you look at their roadmap and strategic vision, they are.  Many of the cloud IDEs are incorporating configuration management like functionality such as pre-configured VMs, and the ability to replicate those VMs by using Docker containers.

To extend it even further; the cloud IDEs like Cloud9 and configuration management tools like Ravello and VisualOps.io are converging with cloud monitoring tools like DataDog,  PaaS tools like OpenShift, and IaaS tools like CloudShare. It seems that what they are building is essentially a hub for all your development, monitoring, and dev environments. A one-stop shop for all the stuff around your DevOps process. PaaS services specifically are trying to be the Chinese menu of development tools, frameworks, and processes. Just look at how fast Azure and AWS are adding new services, as specific as machine learning. The eventually will compete with everyone listed above.

I suspect that the ISVs do not realize the point they are converging. It is common for ISVs to understand very well how their tool fits in their slice of the development process, but not how they fit in the entire process. And they certainly are not aware of each other’s roadmaps. It would be a full time job just to understand this. And many of the tools that do not compete today, might very well be soon.

Better Quality, Better Problem Solving

The good news for you is in this hodgepodge of stuff, eventually you will have fewer, very awesome, choices. The competition is fierce, which is forcing the vendors to focus on quality of product, UX, and solving real, not imagined, problems. After all once you subscribe to their vision, you have to do something with the tool. When the rubber hits the road is when tools win or lose.

To help you make better sense of what is going on, it is useful to think about all tools from the point of view of “what problem does it solve?” Instead of feature and functionality first. You will then understand how tools compete on value, not  feature-by-feature, which is a dangerous trap in the procurement process. And many of these tools can also be used outside of their specific value, so it can be confusing where they actually fit.

For example, I can use a log analysis tool like LogEnteries to set up alerts for system outages, but it is not a system alerting tool like VictorOps. When you do this, then you are measuring the complexity of using a tool slightly outside of what it is built for against the added benefit of using a tool built for the specific task. However, LogEnteries specifically has integrations with alerting tools, and took the additional step of bridging the gap for you. This is very important, which is my next point.

Find a vendor that has solved real problems, an spent the effort to understand the market and delivery pipeline, outside of their specific scope. In my opinion these are the vendors that will be around for the long haul because they are focused on customer results versus selling only a vision.

Too much of a good thing?

The developer tool market is an example of too much of a good thing(s). For organizations this quickly leads to analysis paralysis and pure frustration, to the point that organizations end up doing nothing. This is the most dangerous thing to do. The world is changing fast, and it will change you against your will, unless you move with it. I also do not recommend that organizations fall into the “buy IBM trap”. Sticking with large enterprise tools just because they are safe. These vendors know this habbit, and focus more on what portion of your budget they can get, over providing value. Nor do I recommend getting the latest thing that just appeared out of nowhere just because their concept just might be that magic bullet. Rather I would set all focus on integration and problem-solving. Does a tool solve a clear problem, and does it seamlessly integrate into the flow you designed? Do not expect the tool to design the flow for you.

Just this week a new APM tool appeared on my radar, and tomorrow I’m sure there will be a new testing one. Don’t pound your head against the desk just yet. Just remember you already have a system in place so most of the time there is no rush. Be proactive not reactive, and be deliberate not accidental about your tool selection. In all reality your biggest problem is not going to be the tool you choose. It will be the people and processes you put the tool around.