Rob's Software Engineering Logbook
Sunday, April 02, 2006
Robustness
A term in software engineering that gets tossed around quite frequently is "robustness". I use it myself when I want to compliment a piece of software that I feel adapts well to different environments and handles change well. Robustness is a desirable characteristic.
It is also a loaded term, though. Robustness cannot be quantitatively analyzed. If the requirements state that software should be robust - they would be rejected outright (at least, by smart software engineers), because robustness isn't testable.
Furthermore, is additional robustness something that separates the good software from the bad? Does the fact that Linux can be run on an assortment of platforms (x86, PPC, ARM, etc...) make it superior to Windows from a user perspective? Certainly, the majority of users "NEED" Windows to be productive in the modern business world (at least, they *think* they need it). In this sense, the more robust alternative is less desireable because the establishment of the alternative operating system transcends the Intel-compatible hardware it runs on.
[Editorial Note: I'm partially ignoring Windows CE & other "portable" Windows platforms. In my view, these targets never attained much acceptance. I have no data to support or refute this claim.]
I guess what I am driving at is that robustness is multifacetted. If a piece of software can be coded quickly and addresses a specific responsibility on a certain target operating environment then I would claim that it is arguably as robust as software that takes much longer to code, but handles multiple responsibilities in different configurations (that is, as long as the end user only needs the "specific responsibility" and he has the target operating environment available...).
When TOEs are scarce and responsibilities shift, though, neglibile work needs to be done on the system we said was designed for the general case, while a re-write may be required for the specific case. And the point of this discussion... at what point can the determination be made to put in the extra effort at the onset to design a general system? Doesn't the cost savings achieved by targetting the design to the specific need make it adventageous to skip true robustness in most sitations?
At this point, I am still unsure of the answer to this question... but I will continue to think about it.
[Editorial Note: In the beginning, I defined robustness as "adapts to different environements and handling changes well". I realize I spoke mostly to "adapts to different environments" in my entry. As a software engineer... this adaptability is a strong concern (in my view) for the products which my company makes. If you think this view is narrow-sighted, please let me know.]
A term in software engineering that gets tossed around quite frequently is "robustness". I use it myself when I want to compliment a piece of software that I feel adapts well to different environments and handles change well. Robustness is a desirable characteristic.
It is also a loaded term, though. Robustness cannot be quantitatively analyzed. If the requirements state that software should be robust - they would be rejected outright (at least, by smart software engineers), because robustness isn't testable.
Furthermore, is additional robustness something that separates the good software from the bad? Does the fact that Linux can be run on an assortment of platforms (x86, PPC, ARM, etc...) make it superior to Windows from a user perspective? Certainly, the majority of users "NEED" Windows to be productive in the modern business world (at least, they *think* they need it). In this sense, the more robust alternative is less desireable because the establishment of the alternative operating system transcends the Intel-compatible hardware it runs on.
[Editorial Note: I'm partially ignoring Windows CE & other "portable" Windows platforms. In my view, these targets never attained much acceptance. I have no data to support or refute this claim.]
I guess what I am driving at is that robustness is multifacetted. If a piece of software can be coded quickly and addresses a specific responsibility on a certain target operating environment then I would claim that it is arguably as robust as software that takes much longer to code, but handles multiple responsibilities in different configurations (that is, as long as the end user only needs the "specific responsibility" and he has the target operating environment available...).
When TOEs are scarce and responsibilities shift, though, neglibile work needs to be done on the system we said was designed for the general case, while a re-write may be required for the specific case. And the point of this discussion... at what point can the determination be made to put in the extra effort at the onset to design a general system? Doesn't the cost savings achieved by targetting the design to the specific need make it adventageous to skip true robustness in most sitations?
At this point, I am still unsure of the answer to this question... but I will continue to think about it.
[Editorial Note: In the beginning, I defined robustness as "adapts to different environements and handling changes well". I realize I spoke mostly to "adapts to different environments" in my entry. As a software engineer... this adaptability is a strong concern (in my view) for the products which my company makes. If you think this view is narrow-sighted, please let me know.]
Archives
September 2005 October 2005 November 2005 February 2006 March 2006 April 2006
