People seem to ignore the effects of age and chance.
Something might not need optimization but might need it in the future when the system is more complete, has more users, or has more applications. so in this case, it may a good idea to optimize (up front).
Secondly, there is a lot of code that is slow but not slow enough for humans to feel it positively but it causes sluggishness at the borders of perception. Optimize if possible and/or easy, and/or to add polish, to improve the customer experience, even if the improvement is not obvious.
Especially if the SW has a long life ahead of it. An obvious example would be the fidelity of music.
To assert that only the highest fidelity of audio that is necessary, is desired, is false.
Those blanket "don't optimize don't do this or that" are not universal truths.
Friday, February 27, 2015
Tuesday, February 24, 2015
Good software design and simplistic ideas about life.
Software and Life
When software, or life, has unforseen difficulties, breakage, or simply does not work in unexpected situations or events, is this a problem or an opportunity? Do you believe that a person can be designed not to experience troubles when random difficulties emerge in life? No... the way to do that, is to allow for changes, to test oddball situations. Not to try to make things perfect the first time.
Good software has been stressed and tested in real-life situations, allowed to break, analyzed, and improved.
If the user does something wrong, is it an issue, if the software crashes or breaks, because of the user's error?
Some developers think it's not. However, the best software is written to handle breakage, errors, the unexpected, and oddball cases.
Do car companies design cars to work in ideal conditions? No. They break cars to see what happens, put them under stress, and make cars that can last through problems in the environment and some abuse. The best cars can handle a lot of abuse.
In our lives, when errors occur, do we learn and survive, or simply break and die?
There are two schools in making software: simplistic, and real.
A simplistic school maintains that you design software carefully, so that when it is implemented, it works.
The problem is, no amount of planning can forsee the odd cases. It is necessary to break software, to use it incorrectly, to write code that handles problems of usage and abuse.
The philosophy that problems of usage don't matter, is wrong.
The good philosophy is that we plan to break. We anticipate changes. Software adapts intelligently, and gets better than it would be if not used incorrectly and analyzed.
Changes can break things, but breakage solves design problem that would not be seen otherwise.
Look at living things. They evolve because of those 'survival' mechanisms that are so cruel, and end up producing the most nearly perfect biological creatures you can possibly imagine.
When software, or life, has unforseen difficulties, breakage, or simply does not work in unexpected situations or events, is this a problem or an opportunity? Do you believe that a person can be designed not to experience troubles when random difficulties emerge in life? No... the way to do that, is to allow for changes, to test oddball situations. Not to try to make things perfect the first time.
Good software has been stressed and tested in real-life situations, allowed to break, analyzed, and improved.
If the user does something wrong, is it an issue, if the software crashes or breaks, because of the user's error?
Some developers think it's not. However, the best software is written to handle breakage, errors, the unexpected, and oddball cases.
Do car companies design cars to work in ideal conditions? No. They break cars to see what happens, put them under stress, and make cars that can last through problems in the environment and some abuse. The best cars can handle a lot of abuse.
In our lives, when errors occur, do we learn and survive, or simply break and die?
There are two schools in making software: simplistic, and real.
A simplistic school maintains that you design software carefully, so that when it is implemented, it works.
The problem is, no amount of planning can forsee the odd cases. It is necessary to break software, to use it incorrectly, to write code that handles problems of usage and abuse.
The philosophy that problems of usage don't matter, is wrong.
The good philosophy is that we plan to break. We anticipate changes. Software adapts intelligently, and gets better than it would be if not used incorrectly and analyzed.
Changes can break things, but breakage solves design problem that would not be seen otherwise.
Look at living things. They evolve because of those 'survival' mechanisms that are so cruel, and end up producing the most nearly perfect biological creatures you can possibly imagine.
Subscribe to:
Posts (Atom)