Software engineers love to write code. Give a software engineer a tool that writes the code for them, and they’ll come up with a million reasons why they should code the app instead. While hand-coded software can be more readable and elegant and meet the corporate coding standard, application development can take significantly more time and money. Today, more and more rapid application development tools are available to help software engineers build their applications faster and at lower cost. This article will explore several tips for successfully using Rapid Application Development (RAD) tools to develop embedded software applications.
Tip #1 – Separate generated code from handwritten code
A big problem I often run into when teams start using RAD tools is that they embed their code into the code generated by the RAD tools rather than the other way around. The problem with this is that the RAD-generated code dictates the application’s software architecture, coding styles, and overall build. Teams shouldn’t do this! Instead, the RAD tool should generate a library with hooks that the team’s code can call and leverage to accomplish the desired task, whether it’s running a state machine or an engine. of AI.
The primary goal should be to separate RAD-generated code from hand-written code. Depending on the tool, this may not be immediately possible. For example, it is common to find blocks of code where the developer is expected to insert their code, as shown below:
/* START USER CODE 2 */
/* END USER CODE 2 */
The RAD tool tries to push the developer to become more dependent on the tool! Rather than inserting your application code into these blocks, insert wrapper code that calls the separate application code from the RAD tool. The code will be more flexible, and changes to hand-written application code can be made without modifying the RAD-generated code.
Tip #2 – Model your software
Developing a software model for application code can be a powerful tool. A template will allow teams to build a visualization of their software. This model can then be simulated and run in a host environment to determine if the proposed architecture and components will work as needed. If that doesn’t work, tweaks and tweaks can be made. If it works, developers can auto-generate or manually code the model themselves.
Model-driven development is a technique often overlooked by many embedded systems teams. There is usually a coding rush because the project starts late and the dollars are running out. I’ve found that taking time early in the development cycle to create simulations and validate what’s being built can save incredible development time. Savings are even better if teams can leverage the code generated from their RAD tool!
Tip #3 – Refuse the temptation to “recode”
RAD tools often produce some of the worst C/C++ code I’ve ever seen. If you expect your tools to deliver code similar to your code, that probably won’t happen. Developers working with RAD tools often have two choices to deal with their poor code output:
- Use the RAD tool only as a rapid prototyping tool and code by hand after proof of concept
- Accept the output of RAD tools and move forward
The biggest temptation, especially for developers who are strict with code quality and coding styles, is to throw out all the RAD-generated code and start from scratch. However, in this case, the RAD tool gives a working proof of concept that the hand-written code will attempt to emulate.
The problem with recoding the output of the RAD tool is that if changes need to be made, there is no longer a link between the model generated in the RAD tool and the code used on the device! The possibility of bugs creeping into the code is high. Although the output of many RAD tools is not pretty, they are very functional. If the code can handle the edge cases and work as expected, use the RAD model and just don’t look at the output! By all means, test it, but focus your attention elsewhere.
Conclusions on Rapid Application Development (RAD) Tools
Rapid Application Development (RAD) tools can help teams dramatically speed up their software development. Unfortunately, RAD tools often attempt to become the center of the architecture or produce code that is difficult to read. This article suggests that RAD tools can be tamed by keeping their generated code separate from handwritten code. Today’s RAD tools are better than a decade ago, but we still have a long way to go before they produce generated code that development teams would be proud of. However, a RAD tool can dramatically speed up development if used appropriately.