<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">

Blog

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.

Recent Posts:

My Internship Experience at Erdos Miller
Publish Date 30 Mar 2021 Jonathan EisenbrandtJonathan Eisenbrandt

 

Filtering Basics: Importance of Linear Phase
Publish Date 30 Mar 2021 Jason ThaiJason Thai

Linear phase and computation/memory complexity are important characteristics to [..]

Revisiting OAuth 2 in LabVIEW
Publish Date 30 Mar 2021 John AmstadtJohn Amstadt

Recap In my previous blog, we took a look at how to implement OAuth2 in LabVIEW. [..]

Engineering a Better 3D Print (Part 1)
Publish Date 30 Mar 2021 Michael MaloneyMichael Maloney

3D Printing and its widespread use has been a long time coming and seems to have [..]

NVCC – Intro to Utilizing GPU Power to Offload the CPU Part 3
Publish Date 30 Mar 2021 Jack BakerJack Baker

Assumptions: Machine has a Nvidia CUDA Core GPU (such as a GeForce) with installed [..]

How I Learn New Skills for Personal Growth
Publish Date 30 Mar 2021 Bryce UrestiBryce Uresti

Learning new skills can be quite the task especially when there's already so much [..]

Controlling the Supply Chain Dream
Publish Date 30 Mar 2021 Thomas MathewThomas Mathew

You are out with your friends, bird watching, and nothing could be more peaceful. [..]