CHAPTER 1 ■ INFORMATION HIDING AND APIS
4
model as a replacement of the original domain. Of course, solving this simplified
model will not necessarily result in producing an optimal answer. Therefore, model
improvement efforts are an extra source of changes compared to the previous S type
systems. Nevertheless, the original problem domain doesn’t change over time.
5
3. E Type Systems: These are the most complex systems. They have a complex
problem domain, so simplified models are needed as in the case of P type systems.
However, the execution environment (i.e., real world) is an integral part of it. Many
times, especially in regulated markets, the environment is the principal reason for a
change. For example, accounting software definitely must follow all financial rules
established by a government. The problem is that those changes cannot be always
predicted with 100% accuracy. They do sometimes pose a huge challenge, when
the solution cannot nicely fit into an existing architecture.
If we treat these categories (established in Lehman’s law of software evolution; see [3]) as indicators of
how much we can assume about the future, then as we move from S to E type the amount of “stability”
declines. The main problem with most university curricula
6
and software books is that they dodge E type
systems. On the contrary, reality loves them.
The former Sun Certified Java 2 Developer certification process (I got certified before Oracle took over Sun)
exhibits a lot of the cycle from Figure1-1. The requirements specification for the assignment was intentionally
written in a vague manner. The goal was to leave plenty of opportunities for assumptions, and to somehow
simulate E type systems. The beauty of the certification process was that all assumptions were supposed to be
properly documented. Any unmentioned assumption was treated like an omission, as if the developer didn’t even
think about it during the implementation. For example, if pagination (as a technique to control the amount of
returned data) was not mentioned, but the implementation returned all data at once, then this was an unconscious
assumption (one of the wickedest sort).
7
The assessment phase was basically the evaluation of your submission,
together with the set of associated assumptions. Of course, documented but wrong assumptions were also
penalized. All in all, the soundness of the solution heavily depended on the initial set of assumptions. The points
loss rate was directly proportional to the assumptions die-out pace (unconscious assumptions died instantly).
Entropy and Its Impact on Assumptions
Entropy is a fundamental phenomenon that permeates our physical world. We have all experienced its effects in
our everyday lives. Murphy’s law (you can find lots of references of this kind at http://www.rationality.net/
murphy.htm) even states that “things will go wrong in any given situation, if you give them a chance.” The truth is
that you don’t even need to do anything; entropy will spontaneously raise the chance above zero. Entropy is the
degree of randomness of a system; that is, the level of its disorganization. Nature will always strive to dismantle
any organized system into a total fuzziness. A software system is also on an entropy’s target list.
Suppose we start with an uninitialized computer system. Its memory is filled with garbage. When you turn
on your computer (assuming the memory gets initialized arbitrarily), then the probability is actually zero that
the bytes will arrange themselves into a useful program. If we would like to use this computer, then we need
5
Well, this is not quite true, as the rules of chess did change over its history. However, such changes are extremely rare,
and nobody anticipates further alterations to chess rules in the future.
6
Just imagine the reaction of a student, after she or he is informed (at the last minute) that some of the settings in her or
his semester project was changed! I, as a professor, would surely have consequences.
7
For another example of a wicked assumption (undocumented software features) you can read my LinkedIn blog post at
https://www.linkedin.com/pulse/instead-rules-tell-story-ervin-varga. The example in the article is tightly
associated with an eager empirical programming, where perceived behavior prevails over the specification itself.