Before Covid I use to try and invite random people to lunch. I love gaining new contacts and information. One day I invited the father of student I had mentored in First Robotics. He was a professional programmer, PC software not firmware. I always like to ask about problems people have to see if I can offer a solution. He said that his group have problems with the programmers only programming the "happy path" of the code.
Happy Path Programming
I had not heard this term before and asked about it. He said:
The happy path that is the path the code takes when everything works.
He explained that most bugs he has found are when the code does something that is not on the happy path. For example you put your name in the text field that asks for a phone number.
I knew of this concept but had never labeled it, as such I have adopted the "happy path" nomenclature.
The happy path is what I find is the number one problem with most embedded systems.
That is the developers spend all their time thinking about getting the features added to the project. Only when all the features are added do they think about what happens if you step off the happy path. Usually at this point they realize that they will have to rearchitect the project and rewrite most all the code.
Note that this is also why I dislike using vendor's drivers. The vendor's drivers have in my experience always been written for the happy path, as example code. As such they should never be used for production with out handling the unhappy path.
This is usually when engineers come to management with a huge schedule slip, mountain of bugs, and the project slowly dies as market windows are missed.
What I have found is that good embedded engineers start with the end in mind and with every line of code they think "what happens if this fails."
This really means that they have to start with a good architecture design. This always frustrates project management as the engineer will recommend or try to put into the schedule architectural design. The output of the architectural design is not pretty or sexy for customers and as such appears to be a waste of time to the project managers. The project managers want to show rapid progress at the start of a project and want to have boards designed and firmware for demos as soon as possible. Thus they skip the architectural design and focus the development on the happy path development.
The reality of embedded development is that architectural foundation required to support most embedded projects are all about the same. For example when an error occurs you only have a few options in embedded systems.
- Retry
- Try and reset device with problem and retry
- Reset device as a whole
Of course no matter which option you choose you should log the error.
Having a means of logging errors is usually well beyond the average embedded project.
By starting with an architectural framework where you allow a means of reporting and handling errors opens a world of new options to the developer. As they are writing code and saying "What if this does not work?" They can say "oh we should log that error if this does happen." The one simple act of logging quickly changes the code, project and team where they start thinking and coding beyond the happy path.
If your project is stuck and bugs are growing faster than they are being fixed. Then consider if you are stuck with a happy path development team. If so consider if you have error logging, if not add it ASAP. If this is not enough of improvement contact us and we can help.