11–20 of 39 posts
"the probability of non-trivial defects increases with code size." Intuitively this feels correct, I wonder if anybody has studied it.
Why does he specifically say "non-trivial" defects? The probability of any defect surely increases with code size?
* Use of undocumented magic numbers (1)
* No use of getter/setter pattern
* Inflexible design (datatype of result is fixed, no template pattern implemented)
* Manual memory management (no garbage collection used)
* No infrastructure for automated testing included
* No unit tests available
* Code has not changed for Years (code smell!); Probable stale code, to be removed in next release.
Code inflation nicely cancels out gains from Moore's law. But there's also another interesting phenomenon seen in embedded hardware - it seems that each generation of devices has more (exponentially more?) computing power on-board, while the user-facing functionality stays the same or even slightly degrades. For example, the functionality of today's fridges, kettles and washing machines is equivalent to those made 20…
I would disagree with that on so many points. Today, more than ever we have massive differences. "Hey Siri/Google", the camera functionality is just incomparable, the maps, ...
In the case of consumer white goods the business case is that expensive mechanical components and security mechanisms are replaced by electronic ones that are cheaper. And indeed, counting inflation, today's whitegoods are far cheaper than they ever were. This is happening in power adapters, but also in washing machines and kettles. This means that half the components only exist in the virtual sense and you'd need half the design, a plastic molding factory, and a master's degree to have any hope in hell of fixing them. But they're 1/10th to 1/5th of your monthly pay, and last 2-10 years, so why bother ?
But the story is the same at a high level for everything from cell phone radios to motor controllers for washing machines. Virtual components, simulated in microcontrollers are far cheaper (and far less repairable) than a real component ever will be.
There is a small irony here in the author's use of histogram plotting that performs meaningless perspective rendering - one of the features that has contributed to document-creation software bloat.
Start using libraries for a tiny feature without consider the whole size impact is what is driving code inflation. Now and then I find a very tiny project which executable is big just because they are linking again Boost for just one couple of classes.
Code inflation nicely cancels out gains from Moore's law. But there's also another interesting phenomenon seen in embedded hardware - it seems that each generation of devices has more (exponentially more?) computing power on-board, while the user-facing functionality stays the same or even slightly degrades. For example, the functionality of today's fridges, kettles and washing machines is equivalent to those made 20…
> while the user-facing functionality stays the same or even slightly degrades I would disagree with that on so many points. Today, more than ever we have massive differences. "Hey Siri/Google", the camera functionality is just incomparable, the maps, ... In the case of consumer white goods the business case is that expensive mechanical components and security mechanisms are replaced by electronic ones that are cheap…
Also, I don't feel like the price of appliances was dropping over my lifetime, so I have to ask - where do those apparent savings go? They're definitely not being passed on to consumers.
> I would disagree with that on so many points. Today, more than ever we have massive differences. "Hey Siri/Google", the camera functionality is just incomparable, the maps, ...
I'll grant you camera, because chips and algorithms do get better. Siri/Google doesn't really feel like that much of an achievement over what was possible 10 years ago, except nobody tried to build that product then, and smartphones weren't exactly popular. As for maps, I'll only point to Google Maps application, which is constantly degrading in quality and functionality for the past 5+ years...
There is a small irony here in the author's use of histogram plotting that performs meaningless perspective rendering - one of the features that has contributed to document-creation software bloat.
Perspective is not an expensive feature and I really doubt it would contribute significally to code inflation. Start using libraries for a tiny feature without consider the whole size impact is what is driving code inflation. Now and then I find a very tiny project which executable is big just because they are linking again Boost for just one couple of classes.
There is a small irony here in the author's use of histogram plotting that performs meaningless perspective rendering - one of the features that has contributed to document-creation software bloat.
Perspective is not an expensive feature and I really doubt it would contribute significally to code inflation. Start using libraries for a tiny feature without consider the whole size impact is what is driving code inflation. Now and then I find a very tiny project which executable is big just because they are linking again Boost for just one couple of classes.
It's modular, so you should just have to pull in what you use.
Code inflation nicely cancels out gains from Moore's law. But there's also another interesting phenomenon seen in embedded hardware - it seems that each generation of devices has more (exponentially more?) computing power on-board, while the user-facing functionality stays the same or even slightly degrades. For example, the functionality of today's fridges, kettles and washing machines is equivalent to those made 20…
If you can run android on it, you can increase the size of your hiring pool a hundred fold. That matters a lot for big companies trying to ship products at scale.
Of course I don't get why a toaster or a fridge really needs a CPU at all, but that's another matter.