Software engineers love to write code. Give a software engineer a tool that writes the code for them, and they will come up with a million reasons why they should hand code the application instead. While hand-coded software can be more readable, elegant, and meet the company’s coding standard, developing the application can take a lot more time and money. Today, more and more rapid application development tools are available to help software engineers build their applications faster and at a lower cost. This post will explore several tips for successfully using rapid application development (RAD) tools to develop embedded software applications.
Tip #1 – Separate Generated Code from Hand-Written Code
A big problem I often encounter when teams start using RAD tools is that they integrate their code into the RAD tools generated code 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 general construction. 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 that is to run a state machine or an AI engine.
The primary goal should be to keep the RAD-generated code separate from the hand-written code. Depending on the tool, this might not be immediately possible. For example, it is common to find code blocks where it is expected the developer will insert their code, as shown below:
/* USER CODE BEGIN 2 */
/* USER CODE END 2 */
The RAD tool is trying to push the developer to become more dependent on the tool! Rather than insert your application code in these blocks, insert wrapper code that calls application code separate from the RAD tool. The code will be more flexible, and changes to hand-written application code can be done without changing RAD-generated code.
Tip #2 – Model your Software
Developing a software model for application code can be a potent tool. A model will allow teams to construct a visualization of their software. That model can then be simulated and executed in a host environment to determine whether the proposed architecture and components will work as needed. If it doesn’t work, then tweaks and adjustments can be made. If it does work, developers can automatically generate or hand code the model themselves.
Model-driven development is an often-overlooked technique by many embedded systems teams. There is usually a rush to get coding because the project starts late and is dollars short. I’ve been finding that taking time early in the development cycle to create simulations and validate what is being built can save an incredible amount of development time. The savings are even better if teams can leverage generated code from their RAD tool!
Tip #3 – Refuse the Temptation to “Recode”
RAD tools often produce some of the worst C / C++ code I have ever seen. If you expect your tools to deliver code that is like your code, it’s probably not going to happen. Developers working with RAD tools often have two choices to deal with their poor code output:
- Use the RAD tool as a rapid prototyping tool only and hand code after proof of concept
- Accept the RAD tools output and move forward
The biggest temptation, especially for developers who are strict with code quality and coding styles, is to throw away all the RAD-generated code and start from scratch. However, in this case, the RAD tool gives a functional proof-of-concept that the hand-written code will attempt to emulate.
The problem with recoding the output from the RAD tool is that if changes need to be made, there is no longer any connection between the model generated in the RAD tool and the code used on the device! The opportunity for bugs to creep into the code is high. While the output from many RAD tools is not pretty, they are very functional. If the code can handle corner cases and work as expected, use the RAD model, and just don’t look at the output! By all means, test the heck out of it, but focus your attention elsewhere.
Conclusions
Rapid Application Development (RAD) tools can help teams dramatically accelerate their software development. Unfortunately, RAD tools often try to become the center of 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 hand-written code. RAD tools today are better than a decade ago, but we still have a long way to go until they produce the generated code that development teams would be proud of. However, a RAD tool can dramatically accelerate development if appropriately used.
