People use and defend the use of all sorts of methods and tools for building software. The number and range of methods and tools is overwhelming. Is Occam optimality yet another entrant to be added to the already-too-long list? No. I hope that the notion of Occam optimality will be understood to be independent of all those methods and principles, and will provide a way to both improve each of them and, in some cases, select among them.
If the notion of Occam-optimality is correct, it stands above and cuts across all methods of building software. It is a principle that enables you to take two efforts to build a program in the same environment and tools, and say objectively which is better.
It is certainly true that some tools and methods make it easier to achieve Occam-optimality than others. But it is important to understand that Occam-optimality is not primarily about judging tools and methods – it is a notion of optimality that can be applied given any selection of tools and methods. Programs can be written in assembler language (assuming there’s a good macro pre-processor) that are Occam-optimal, and in fact it is easy to understand the concept in that environment, since everything is laid bare.
If most current ways of thinking about programs are like algebra, then the analysis and understanding of Occam-optimality is like calculus. Just as calculus doesn’t replace or criticize algebra but is built on it and extends it, so is Occamal analysis built on existing methods and tools of program construction. Just as calculus provides tools that didn’t exist before, like methods for calculating the area under a curve or the zero or minima of a curve, so does occamal analysis enable us to understand what “optimal” really means for most programs, and gives us guidelines and a way of thinking to enable us to construct programs that approach occamality.
Unlike the myriad algebra-like methods of program design and construction, an occamal program that meets the business intentions is also very likely to be optimal in terms of all the other goals that business people have: it will be as efficient as possible to define, build, test, document, deploy, learn and support. Most important, it will be possible to modify and enhance it more quickly, safely and inexpensively than any other kind of program. To the extent that the program fails to meet important expectations on any other grounds, e.g. performance, availability or attractiveness, a program that is occamal lends itself to alteration to meet those expectations better than a program which is sub-occamal.
Once this criterion is understood and accepted, our tools and methods will evolve rapidly to achieve the maximum possible productivity in software design, construction, support and evolution.
Focusing on the occamality of programs is a way of focusing on what we most care about in software. It doesn’t eliminate our other concerns – we still care that programs perform reasonably, that databases avoid corrupting data, etc. But an amazing number of those other concerns will be taken care of by-the-way if our programs are occamal, and if they’re not, we know that occamal programs are almost by definition the easiest to change to address any need or fill any gap.
I worked with a company having horrible problems with the administrative workstation of their storage product. It took a long time to load and many seconds to respond to reasonable-seeming requests. Its user interface was inconsistent and it took a very long time to update to reflect changes and new features in the underlying product of which it was a part. Looking under the covers, it turns out there were more than 200,000 lines of what turned out to be java code, and it was really hard to say what useful function large chunks of it were performing. Java was selected because the people thought it was modern, object-oriented, and would let them build re-useable components and other good things. Then they just started writing code, and here we were.
There were lots of arguments, pro and con, about whether java was any good, all of which were beside the point – wrong discussion. After a great deal of struggle, the whole thing was gutted and replaced with less than 20,000 lines of code and definitions. The people doing the work did not concentrate on performance, changeability, or other architectural concerns – their main goal was to make it small. When they were done, and they did it quickly, they had a complete replacement, a consistent user interface, and it magically became really fast and easy to change!
Comments