From the trenches: The risk of optimization
Why optimize for functionality and update ability before the code optimization
Background
Early optimization in software development refers to the practice of trying to optimize code performance or other metrics prematurely before the code has been fully developed and tested. While optimization is an important aspect of software development, focusing on it too early can have several risks:
Wasting time and resources: If you optimize code prematurely, you may end up wasting a lot of time and resources on code that may not even be used in the final product. This can lead to delays and increased development costs.
Over-complicating the code: When you optimize code too early, you may end up adding unnecessary complexity to the codebase, which can make it harder to understand and maintain.
Hindering flexibility: Early optimization can also make it harder to make changes to the code later on, as it may be harder to modify optimized code than unoptimized code.
Instead of optimizing for performance or other metrics early on, it is generally better to focus on functionality and update ability. This means ensuring that the code works as intended and can be easily updated and maintained in the future. This approach has several benefits:
Faster development: By focusing on functionality first, you can develop and test code more quickly, which can speed up the overall development process.
Easier maintenance: By ensuring that the code is easy to update and maintain, you can reduce the risk of bugs and other issues arising in the future.
Better user experience: By prioritizing functionality, you can ensure that the software works as intended, which can lead to a better user experience.
Once the functionality has been established and tested, then you can start thinking about optimization. This way, you can ensure that you are optimizing code that is actually being used and that is easy to modify if necessary.
The learning
During my embedded development period, middle of the 80s, I created software for a range of boat instruments. Boat instruments, like many other embedded systems, have historically used ROM (Read-Only Memory) because it provides a non-volatile storage medium for storing firmware or software that controls the instrument's operation.
One of the main advantages of using ROM for storing firmware or software is that the contents of ROM cannot be easily changed or overwritten once they have been programmed. This is important because the firmware or software that controls the operation of the instrument is critical to its proper functioning, and any errors or bugs in the code can potentially lead to dangerous situations on the water. By using ROM, the manufacturers of boat instruments can ensure that the code controlling the instrument's operation is fixed and reliable.
Additionally, ROM can be less expensive and simpler to implement than other types of non-volatile storage like EEPROM or flash memory, which can be more expensive and require more complex programming and management.
However, in more modern boat instruments and other embedded systems, the use of ROM has largely been replaced by other types of non-volatile storage like flash memory, which allows for easier updates to the firmware or software controlling the device's operation. This can be especially important in situations where updates are needed to fix bugs, improve performance, or add new features.
The system on a chip used at the time had limited space for code. At the time I was very competitive and had a competition with a friend and classmate to design the smallest and most performant math library functions. One of the functions was to communicate with satellite navigation equipment using the NMEA messaging protocol. In this functionality, there was a need to implement arctan, which in turn needed to do divisions. High-precision division with 32-bit resolution. You may ask, this is not high-precision! I would respond, remember this is way back and this specific SoC (from NEC) had 4-bit registers and very little memory. To make a long story a little shorter, after a few iterations of beating each other in having the best code implementation. I ended up having the shortest version and “won” the competition. The project was a success because the code could fit in the system ROM and it contained code for four different instruments and it save manufacturing. However, almost a year after ROM was masked there were reports of an error in mathematical calculation occurring when the boat went in exactly in a certain direction. The updated code was now located in an (E)EPROM, which could be erased after manufacturing. It is of course more expensive but now updates were cheaper.
Applying the learnings during base station design
Keep reading with a 7-day free trial
Subscribe to Full stack programmer v0.1 to keep reading this post and get 7 days of free access to the full post archives.