Monday November 4, 2007
Quality of Software is related to time in use
I was just reminded, rudely reminded, of a law I coined some time ago: The quality of a software product has to do only with how long it has been in use, or alternatively with how many bugs have been reported against it.
I was editing this page with Quanta Plus, which crashed, and it didn't recover my edits, not cleanly, and I couldn't find where it put the back file.
I am re-editing this using good ol emacs because I know what it is going to do, and I know what to expect because emacs has been around since before the epoch.
Javascript and the pitfalls of OOD
I have been investigating Javascript since Friday last because of a comment someone made to me last week. I have learned some language basics, logic, calling functions, dealing with errors ( try/catch ) same as one would do learning C++ or Java and like those Object Oriented languages I can see a fundemental problem, a gotcha that OOD obfescates.
All programming languages or paradigms or empires have flaws. Sometimes these flaws prove fatal, e.g. does anyone write PL/1 anymore. Other old languages thrive, why? And is OOD a panecea immune from the trash heap? It has been touted as the way to fix the reliability problems of building large applications where in time a team of programmers step on each other's work, producing side-effects and causing havoc. I think that diving in to any OOL reveals a serious problem that isn't adequately addressed.
The big challenge with dealing with an OO language or any library using objects for a programmer is to learn to use the methods and objects. Even to the user this can be a problem if he is confronted with an alphabet soup of names and various prototypes. IEDs don't really do a good job yet of revealing to the programmer what he can do, and the hardcopy documentaation that would be needed would break your arm, do any small Java books exist?
The answer to that question is "no", and it is why Java's utility is limited and the challenge of wading into huge class libraries limits the long-term usefulness of any OOD system. The new skill required for continued success of OOD is skill at designing prototypes and how well is a class library designed, and documented. The IDEs must be able to get documentation for several languages and libraries and present it to the developer who may be offline and have no hardcopy manual. OOD ofescates bad design and compleity into class libraries and creates a steep learning curve for the developer. This may be good for cartels of developers, but it is guarenteed to shorten the life time for software.
