Software engineers use tools to document requirements and design, to code, debug, test, and deploy as well as document and support the software they develop. The fundamental purpose of tools has not changed over time but the complexity and availability of tools has.
A resource from XebiaLabs, illustrated above, is a useful example of the choices available. At the link: https://xebialabs.com/periodic-table-of-devops-tools/ one can explore the table and learn more about the tools mentioned. The resource is thorough, but somewhat angled toward to the independent vendors and the open source community of tools, with major integrated development environments such as IBM Rational not considered.
The availability of engineering tools at little or no cost from the open source community and/or bundled with cloud providers such as Amazon Web Services has really changed the tool challenge for many teams. In the past I would find situations where teams were “making do” with inadequate tools due to the inability or unwillingness to spend the high cost for some of the best tools. Today it is almost the opposite. Teams are overwhelmed with tools choices, and are often facing the challenge of having underutilized or misunderstood tools causing lost productivity. My observation is that leads should not underestimate the importance of the development environment architect, and allocating enough time to having an up-front plan, training and support for the development environment – it shouldn’t be an afterthought, nor should it be something left to the developers to do for themselves.
Finally, one observation I would have is that maturity and availability in testing is less prevalent. There are a lot of tools available for debugging and executing unit testing, but tools to manage the process of integration and product testing are still coming from vendors at cost.