The very first value statement of the Manifesto for Agile Software Development is that “we come to value individuals and interactions over processes and tools”. Yet, you might find that embedded developers don’t just love their tools but often obsess over them. I’ll often be interrupted while teaching a class by someone asking, “What tool did you use to do that?”. Blogs and videos that discuss tools seem to be much better than those that cover processes, language skills, etc. Nevertheless, developers are very interested in tools, which brings up an interesting question:
What is the most essential tool available to embedded developers?
When asked a question like this, I have an insightful and pre-coined response, “It depends!”. Every developer and every team faces different challenges and environments that may dramatically change what tool gets them the most significant value. However, I have found it helpful to recognize that there are generally three areas where having the right tools in place can help teams succeed, provided they remember that individuals and interactions are more important. You’ll find that these align with what I call “the embedded software triad”.
Software Architecture and Design
Software architecture is critical to every embedded software system that needs to be scalable, flexible, and reusable. A software architecture acts as the blueprint for what the software will do. Therefore, having tools available to build this blueprint for developers is critical.
Software architecture tools can range from tools where the architecture is created in UML to tools that can model the system and allow it to be simulated. These tools can be open-source, commercial, and even home-grown using Python or other host-based languages. The trick is to find tools that allow a clean and clear architecture to be developed, tested, and even deployed to minimize development time.
I’ve found that the software architecture tools that I use tend to be a bit more stable over time, although I believe there is a lot of improvement that can be made to tools in this area.
Agile, DevOps, and Processes
No matter how big or small your team is, you need processes to ensure consistency and quality in the software being developed. I’ve worked with teams with zero processes that sling code around like the wild west and disciplined and process-oriented teams. Over time, it’s the process-oriented teams that I’ve seen be the most successful.
Many excellent tools are available today that can help teams manage their day-to-day activities. Some tools will vary based on whether you are using Agile methodologies and even depending on your methodology. For example, some tools enable Test-Driven Development and Continuous Integration / Continuous Deployment (CI/CD). Other tools may just help you define what on Earth your process is. (Even a blank process can tell everyone that someone needs to take ownership of the processes).
I’ve found that process tools are constantly changing and evolving. Over the last few years, the project management tools have become more stable, but improvements in tools that enable CI/CD and DevOps are driving rapid change.
Software Development
Software development tools are the ones that developers are usually the most interested in. These tools allow code to be edited, compiled, linted, tested, and analyzed. You’ve probably seen a big push by developers to use open-source tools. These are great and can provide a lot of low-hanging value, although they can often be limited in capabilities. Commercial tools can hurt the bank but can add flexibility and features that are often not present in free tools. (Has anyone found a free open-source linter for MISRA-C?).
I’ve found that tools associated with software development are constantly changing. If I look at the tools I used two years ago to develop software with what I use today, I’ve probably changed half the tools I use. The tool turnover might even be accelerating. As you look to leverage AI, tool churn will increase dramatically (although I suspect with what I’ve seen so far, so will bug counts!).
Conclusions
The tools that embedded teams use on a day-to-day basis are constantly changing and evolving. A tool critical to you today will likely be discarded a few years from now for some newer tool offering lower costs, faster time to markets, or a significant return on investment for the business. While the tools we use evolve and change constantly, I think we can agree that it’s critical to have tools that allow you to develop your architecture, create and maintain your processes, and develop your software. Which tool is most important will depend on you and your work environment.
With that said, what tool do you find to be the most important to you daily?
Note: I’ve intentionally not given specific tool names in this post to avoid any of my personal biases and/or areas where there may be conflicts of interest. I hope you’ll take a moment to share with other readers what tools you have found helpful!
This is a guest post from another webpage we are sharing this link an more
go to our blog for more blogs about software.
ความคิดเห็น