jedishrfu
Mentor
- 15,593
- 10,361
One reason for code bloat is the use of libraries that do what you want and more. Unfortunately, sometimes you can't just discard the more part.
One example from my recent past is developing code in python using Anaconda. Python modules call in other python modules so while you may want some particular function in a given module. It will pull in other modules you don't need.
The upside of using other peoples code is that you don't have to write it only use it as it probably had better testing done depending on its maturity of course.
We code to fit into the hardware we have and if we need a lot less memory then it can be engineered out of the final product. But wait, we may need to patch or update the code and we may need that memory that was removed so we must balance out our tradeoffs.
The old programming mantra still holds:
_ I can make it fast
- I can make it cheap
- I can make it reliable
pick any two and let me know.
Of course, bosses today will pick two and then ding you on the one they didn't choose.
Its good that you have an engineering background but sometimes that will get in the way of software development.
On one project I worked on, the engineers saved money on a signal pattern generator for high speed memory testing by packing the internal looping code ie by using 14 bit counters in one place and 12 bit in another...
It was a bear for programmers to build loop code loads as we had to constantly pack stuff up and decode errors returned to figure out what was happening during a test.
The hardware design didn't factor in the programmer's needs in the interest of getting the cheapest and fastest hardware possible.
I remember one hardware manager showing empathy to the programmers by saying he once wrote a BASIC program and can understand the difficulties we faced. We just looked at each other.
Some of the engineers in our group looked down on the programmers too. We needed to test a C based monitoring program that handled 200 sensors in a bay continuously for a few days. However, every morning we discovered it was swapped out for a PC BASIC program.
When asked why the engineers said our program ran too slow for their needs. Upon further investigation, we discovered that their program ran faster because it monitored only 20 sensors continuously. What a crock? Ours was configurable and could have done the same if they told us.
The payback came when they had some test program written in BASIC that exceeded 64K (PC-DOS BASIC limit) and they wanted our help to fix it. We suggested removing comments and other memory saving tricks but to no avail. Finally we said well I guess you'll have to recode it in C like we told you months ago. They were not happy campers after that.
One example from my recent past is developing code in python using Anaconda. Python modules call in other python modules so while you may want some particular function in a given module. It will pull in other modules you don't need.
The upside of using other peoples code is that you don't have to write it only use it as it probably had better testing done depending on its maturity of course.
We code to fit into the hardware we have and if we need a lot less memory then it can be engineered out of the final product. But wait, we may need to patch or update the code and we may need that memory that was removed so we must balance out our tradeoffs.
The old programming mantra still holds:
_ I can make it fast
- I can make it cheap
- I can make it reliable
pick any two and let me know.
Of course, bosses today will pick two and then ding you on the one they didn't choose.
Its good that you have an engineering background but sometimes that will get in the way of software development.
On one project I worked on, the engineers saved money on a signal pattern generator for high speed memory testing by packing the internal looping code ie by using 14 bit counters in one place and 12 bit in another...
It was a bear for programmers to build loop code loads as we had to constantly pack stuff up and decode errors returned to figure out what was happening during a test.
The hardware design didn't factor in the programmer's needs in the interest of getting the cheapest and fastest hardware possible.
I remember one hardware manager showing empathy to the programmers by saying he once wrote a BASIC program and can understand the difficulties we faced. We just looked at each other.
Some of the engineers in our group looked down on the programmers too. We needed to test a C based monitoring program that handled 200 sensors in a bay continuously for a few days. However, every morning we discovered it was swapped out for a PC BASIC program.
When asked why the engineers said our program ran too slow for their needs. Upon further investigation, we discovered that their program ran faster because it monitored only 20 sensors continuously. What a crock? Ours was configurable and could have done the same if they told us.
The payback came when they had some test program written in BASIC that exceeded 64K (PC-DOS BASIC limit) and they wanted our help to fix it. We suggested removing comments and other memory saving tricks but to no avail. Finally we said well I guess you'll have to recode it in C like we told you months ago. They were not happy campers after that.