J.P. Morgan 5

Perhaps you know someone afflicted by the BCL mindset. It is not a condition that lifts when the subject goes for lunch, sees a movie, or dreams at night. It is full-time -- 24 by 7, in business-speak -- an unrelievedly twisted, perplexing way of seeing, hearing, and having and expressing thoughts.

The BCL team's conception of my task was that it was to be a "gap analysis." What "gap" was I supposed to analyze? Well, if you're supposed to evaluate a car, you can describe its good points and bad points. Or you can describe how it differs from the ideal car -- the "gap" between it and the ideal. This nuance, which I confess was lost on me, seemed very significant to the BCL team.

They had presumably attempted to convey their conception to my boss Bob when the task was arranged. I was not privy to these discussions. (Managers commonly like to think of a "technical resource" as a sort of gun, which does not need to be consulted as one is aiming. Or maybe we're too expensive for the endless meetings. At any rate, lots of stray passersby get shot.)

Bob, not one to agonize over subtleties, had simply asked me to evaluate the product, and that's what I set out to do. The product to be addressed was actually "EBPFC," sometimes called "EB4PFC" -- a successor product to BCL. (The generational shift made little difference. Albatrosses beget albatrosses.)

I had the chore of setting up the product and trying to get something, anything, to work in the first place. The product was typical for the software industry in that it failed right out of the box. But I consulted BCL team member Steve Katz regularly, and he acknowledged the defects I encountered and helped overcome them.

In the course of these consultations I emailed him an inquiry about certain features that seemed to either not work at all or be pointless, sincerely thinking I must be missing something. He replied:

From: Steve Katz
06/19/98 04:14 PM
To: Uriel Wittenberg
cc: Robert Zolkiewicz, Marc O Becker, William Green, Millard Brown
Subject: Re: EB4PFC

While your comments are accurate, please include them in your gap analysis of EBPFC vs. your ideal PB development environment. Note that some of the current deficiencies of the library are known, even if they have not as yet been addressed.

Your earlier bulletin board posts and messages indicated a fair amount of familiarity with EB4PFC. My interpretation of the purpose of the gap analysis is for you to tell us how and why the library is far from your ideal PB development environment. From that we will be able to identify areas for improvement and also make sense as to why, from a technical perspective, you characterized the library as "utterly misconceived" and "not recommended for use".

I wrote back:

From: Uriel Wittenberg
06/22/98 11:57 AM
To: Steve Katz
cc: Robert Zolkiewicz, Marc O Becker, William Green, Millard Brown
Subject: Re: FW: Re: EB4PFC

Thanks, the training manual could be useful.

You're more or less correct as to the purpose of my analysis, though I'd describe my objective as an open-minded evaluation rather than a retrospective justification of my earlier comments.

This objective is hindered by the lack of documentation and the inadequate or malfunctioning demo apps. I made some use of BCL at one point, but I wouldn't claim great prior familiarity with the product.

Incidentally, I had never revealed my Icon Solutions experiences to them or to others at Morgan, since the termination etc. was somewhat sensitive and would only invigorate my opponents in prejudiced councils conducted in my absence (except that I may have confided in Bob -- I forget). I had ignored the BCL team's earlier demands to know where I'd had experience with BCL.

The above communication, specifically its innocuous characterization of the point of the analysis, inexplicably stirred VP Marc O. Becker to fury. He jumped in from the sidelines with:

SendTo: Uriel Wittenberg, Robert Zolkiewicz
CopyTo: William Green, Steve Katz, Millard Brown
From: Marc O Becker
PostedDate: 06/23/98 10:59:03 AM

Wait a minute!! Enough talk here. Uriel, what we asked for is a gap analysis, not an open-minded(!) evaluation of our library. Shouldn't you have already done this before making your anti-library recommendations of the last few months?

As for documentation, we have given you a user manual, an object reference, and a training manual. Isn't this enough? This should provide the primary features, etc.. Again, if you are not familiar with the product, why have you been lambasting it all along.

Finally, there are simple/sample apps with both BCL and EBPFC (the Features demos) that illustrate the use of the product's most important features. If you think these are a problem, please note this in your gap analysis.

Can you just get to work!

Marc

People did not express themselves like this at Morgan.

As I reflect on my overall Morgan experience, the "gap" that occurs to me is that I actually never met Becker. I'd emailed him months earlier when he complained to Bob about me: "Since your grievance is with me, may I suggest that we discuss this directly? I would be happy to meet at your convenience." He'd never replied.

Bob raced to forestall my anticipated response to Becker: "Do not reply to this. There is nothing constructive to be gained here." His email (sent only to me) was timestamped two minutes after Becker's.

I complied. And a short time later I sent:

From: Uriel Wittenberg
06/23/98 12:26 PM
To: Steve Katz
cc: Robert Zolkiewicz, Marc O Becker, William Green, Millard Brown
Subject: Re: FW: Re: EB4PFC

Since I'm leaving July 10, I'd like to offer you the opportunity to respond to specific criticisms as I document them, prior to completion of the entire evaluation.

Attached was a short document that criticized a particular feature of the product.

I am deeply sorry, list members. Although many of you ... no, probably all of you, will find this unendurable, I am going to quote the document here. I want to make it clear that it was very specific in its criticism, and that the aspect of the product I was criticizing imposed a serious time/labor cost on software developers. Also, the document is generally simple enough to be understood by the layperson -- or managers, which was the intention:

For the purposes of this document, let us define "Puritanism" as follows:

A rigid adherence to painful, tedious and inefficient practices in the name of righteousness.

"Constants" objects are a widespread form of puritanism. They create work, increase obscurity, and produce no benefits.

The use of "Constants" objects possibly has its roots in a fallacious view that literals should be completely banished from programs because they are wrong, or impure. This is a misunderstanding of a reasonable CS 101 stricture against certain types of literals. For example, it's a bad idea to hardcode the string "New York" in a program written to process data relating to New York, because a new, unforeseen requirement may arise for the program to be used to process data relating to "Toronto". If "New York" were hardcoded, then each instance would have to be found and replaced in order for the program to function properly for "Toronto". If instead a variable is used, it is a simple matter to change the single line of the program in which "New York" is assigned to the variable.

A totally different situation exists when a variable's value represents a system of codes that is independent of the world outside the program. For example, one might write a function

CHARGET(S1, S2, CODE)

to take as arguments 2 strings, S1 and S2, and a code indicating one of the following:

- "C" (for "common"): return all characters appearing in both strings

- "X" (for "exclusive"): return all characters appearing in one or the other but not both strings

In this case there is no reason not to hardcode the third argument in all the places where the function is invoked. There is no way a need will arise in the future to change all C's to X's or some other value.

Striving to create a system devoid of such literals is doomed to internal inconsistency in any case. To completely renounce literals, one would have to recognize commonplace enumerated-value arguments to PB primitives (such as primary! or cascade!) as literals that need to be replaced as well. To be thoroughly consistent, even "true" and "false" should be recognized as literals. Such extremism is obviously absurd.

COSTS OF THE "CONSTANTS" METHODOLOGY

The "constants" methodology (really an ideology) creates a very substantial drag on development, grossly increasing the complexity and tediousness of programming any system. As an illustration, consider the "sample application" provided with EB4PFC.

n_cst_sample_appmanager:constructor includes the line:

inv_Splash.of_SetSource(This.c.Source.IFC)

To thoroughly understand this, the person reading the script has to figure out that "c" is an instance var of type "n_cst_constants", though it's not declared in n_cst_sample_appmanager itself but in some ancestor thereof; that "source", in turn, is an instance variable declared in some ancestor of n_cst_constant as type "n_constant_source"; and that ifc_n_constant_source, the parent of n_constant_source, contains the following instance var declarations:

constant integer PFC = 1
constant integer IFC = 2
constant integer USER = 3
constant integer OS = 4
constant integer TEXTFILE = 5
constant integer DATABASE = 6
constant integer DW = 7

//BTG: Added constant
constant integer BOSS=9

What we have here is not even a single constants object, but a hierarchy of constants objects. This hierarchy must be understood and referenced throughout development by all developers. It reflects a "central planning" ideology in which the organizing principle demands that complete information (ALL constants, for ALL functions anywhere in the system) be preserved in a central location.

The central control fixation imposes a great task upon developers: all additions, all changes to the set of constants used throughout the system must be centrally maintained. All invocations of functions involving such values must be preceded by a navigation through the constants hierarchy; the constants relevant to the function to be used must be identified and understood.

Consider the alternative, childish in its simplicity: an of_SetSource() function that takes a string argument, value "pfc", "ifc", ., and performs accordingly. No one uninvolved with of_SetSource() has to know anything about its argument. The person calling of_SetSource() looks in the obvious place -- of_SetSource() itself, guaranteed to be up-to-date -- to determine which argument to pass.

But looking "inside" a function one is calling violates "encapsulation" (though only in the most technical, literal-minded sense), which constitutes an outrage for puritans. Thus does religion overcome common sense.