Good Firmware Programming: Quantitative vs Qualitative
Write Software for others as you wish they would write for you.
It is perhaps the hallmark of a good coder to produce high quality code. No engineer would set out to create poorly written programming. The ultimate goal of a system design is the satisfy the stated design objectives for the given project, objectives such as accuracy, stability or I/O relationships. However, without following good procedure during the development and evaluation phase, the produced code can be hard to test and even harder to change. This, therefore, poses an important question. What constitutes good code? After all, how can we write good code if we don’t even know what good code is? There are two performance criteria which we can use That of being quantitative and qualitative criteria.
Quantitative Performance Criteria
Quantitative criteria involve dynamic efficiency, static efficiency and accuracy. It is generally considered the simpler of the two criteria to use as it produces a numerical value we can use to judge the efficiency of our code.
1. Dynamic Efficiency
Dynamic efficiency is basically the measure of how fast a program executes. Commonly, this is measured in either seconds or CPU cycles. Dynamic efficiency can be defined using the total execution time necessary to finish the program or it can be used to measure specific tasks and code sections. Often, a key trade off that is present with dynamic efficiency is the balance of clarity and execution speed. There are many programming tricks to improve execution speed but doing so often obfuscates the code. This means that a common error in firmware programming is to excessively sacrifice clarity for the sake of execution speed. This results in code which runs fast but is hard to change or upgraded.
2. Static Efficiency
Static Efficiency is the memory requirements of the program. This means static efficiency is the hardware requirements of the program, specifically for embedded, the ROM and RAM requirements. Embedded systems usually have limited amounts of memory available for programming code and programming data. This means that the total memory needs for a developed program must fit within the available memory space. Static Efficiency usually presents a trade off with Dynamic Efficiency. Depending on how certain algorithms are designed, more memory may be required to improve execution speed. This means that excessive focus on trying to improve dynamic efficiency, saving memory, could cause the program execution to take longer.
Qualitative Performance Criteria
Qualitative criteria is harder to define as it is measurement of efficiency that cannot be assigned a numerical value. This means that qualitative efficiency can be hard to define. Therefore, the best way to consider this performance criteria is to ask the following 3 questions:
- Can you prove your software works?
- Is your software easy to understand?
- Is the software easy to change?
Due to the nature of these questions, there is unfortunately no real procedural methods to evaluate qualitative efficiency and ways to ensure good qualitative performance. The only real good suggestion on ways to improve qualitative performance is to use effective coding practices and develop good programming habits. There is a wide array of tips and tricks on good programming habits and equally as many good coding practices. Some examples could be to use self-documenting code, abstraction, modularity and layered software. The key than is to find the techniques and habits that work well for you.
A good benchmark to use in order to evaluate if you are a good programmer with high qualitative efficiency is to see if you code can be understood over the long term and if others can understand and make changes to your code. A good way to test yourself on these benchmarks is to performance the following exercise. Find a major piece of software that you have written over 12 months ago. Then, see if you can still understand what you have written enough to make minor changes to its behavior. A second test is to exchange code with a peer that you have recently written. If you and your peer can understand the exchanged code enough to make minor changes. Passing both of these evaluation exercises, than it is a good indication that of high qualitative performance.