Provocation - The Future of Objects

Provocation ”The Future of Objects

Thinking can be focused toward the accomplishment of a task. All of the material in this book so far is intended to aid developers in that kind of thought. To conclude, however, I would like to provoke a different kind of thinking ” speculative thinking. Specifically, what might happen if all of the ideas, philosophies, and metaphors presented in this book were taken to the extreme? The following story is one possibility.

Circa 1998 a small group of programmers decided they were mad as hell and not going to take it anymore. Although the rebellion came in many flavors, the most prominent example of it was extreme programming (XP). Similar, concurrently active groups considered themselves agile and formed , with the XPers, the Agile Alliance. Xgilista is an umbrella term covering the spectrum of extreme and agile approaches to software creation.

Among other things, Xgilistas rejected the prevailing idea that software projects, particularly large mission-critical projects, required massive amounts of up-front analysis, design, and specification. They claimed that it was quite possible to realize such systems with an incremental process that was highly disciplined, human-centric, social, and ethical.

Large, successful systems emerged from incremental development ”existence proofs of yet another old idea. Grady Booch, in Object-Oriented Design, 1991, stated that everyone knew that the only way to build successful large systems was to evolve them from successful small ones.

In rejecting up-front design, Xgilistas essentially rejected the need for large, monolithic programs. They challenged, implicitly and explicitly, the assumption that large systems were actually required.

XP focus on delivering the simplest possible deliverable capable of meeting a real but discrete business need had an unintended side effect. (At least, this result was never explicitly stated as an expected outcome of XP, but one should not underestimate the sly, subtle, and covert intent of a Ward Cunningham or a Kent Beck.) Users started to see their requirements in a very different light. Instead of automatically thinking they needed huge, monolithic software systems, they started to request a set of small, targeted software-based business tools instead. The perceived role of software changed dramatically. Users started to ask for objects capable of providing specific and limited services. The utility of such objects was based on how limited an intrusion they made into the business process and how faithfully they simulated a business role in that process.

Objects (applications are just composite objects with collective responsibilities) came to be seen as analogous to new employees . Just as you would hire a human being with specific skills to perform some well-defined job function, so too businesses started to hire individual objects instead of massive systems.

In retrospect, this outcome should also have been obvious. In the late 1800s, Pareto s 80/20 law was formulated. Empirical study of the actual use of programs such as Microsoft Windows, Microsoft Word, WordPerfect, and so on revealed a variation of Pareto s Law ”80 percent of the users used 20 percent or less of the functionality offered by such programs. No one used all of the features. So why were they built? Why did companies spend millions of dollars on monstrous dinosaurs such as SAP and its kindred integrated applications ? Market forces and management folly is the short answer.

Until Xgilistas demonstrated differently, advocates of monolithic formal systems claimed that the incremental, bottom-up approach could not yield, at least efficiently , systems that were capable of controlling large businesses or complex systems such as air traffic control. The XP mantra, Architecture emerges, was dismissed as absurd. But architecture did emerge. Executives and even entire corporations are, after all, just another kind of user with focused business needs. Satisfaction of those needs did require aggregation and distillation of results generated by other objects and job processes. But this was addressed with judicious use of the observer pattern.

Xgilistas finally broke the back of the prevailing software engineering and computer science myth ”to wit, software is formally defined and constructed . Users, and even managers, were finally ready to accept what objects had offered 30 years earlier.

Enter the Objectionary , a combination of dictionary and object factory. The Objectionary is nothing more than the product of taking object ideas ”as originally voiced ”seriously. The salient features of the Objectionary include the following:

• The Objectionary itself is a kind of object vending machine, dispensing objects of various types upon request.

• The total number of Objectionary objects is less than 2000, a number that continues to be sufficient to assemble every software application attempted. (Remember the Lego Brick metaphor and the discussion of how many objects ”classes, really ”are necessary.)

• Each object is an autonomous executable entity. Smalltalk objects are freed from their dependence on image environments.

• Every object has a unique ID and a unique address ”a realization of Alan Kay s suggestion that every object have its own URL.

• Objects are nothing more than collections of objects. After all, everything is an object. This means, of course, that messages and methods become first-class objects in their own right.

• Objects are fully executable ( precompiled byte code strings ) but do require a hardware-specific Virtual Machine (VM) for access to primitive hardware services.

• There are a few key abstractions, such as the self-evaluating rules conceived of by West and implemented by Johnson. Their work essentially reified source code statements into first-class objects that could be modified at execution time.

Access to the Objectionary almost eliminated one profession ”that of programmer ”and replaced it with another, application assembly specialist . (Again, remember the Lego Brick metaphor and its differentiation between creators and assemblers.) These specialists adopted the rather ugly, but descriptive, appellation of collagist , reflective of the kind of artist who creates new works by assembling materials.

End user computing ”for real, not the pseudoprogramming that had stifled earlier forays into this area ”became all the rage. User-created software was quite analogous to the Lego Brick constructions of children ” workable but lacking in certain qualities. Some novice assemblers had a knack for putting together objects in such a way that the resultant assemblies not only were functional but were starting to become beautiful. Others noticed and were more than willing to compensate such hobbyists or tinkers to assemble on their behalf .

Software assembly became a craft, just as programming once had been. Collagists formed a community of shared expertise. But this time the art went in a much different direction than programming had almost 50 years before. The expertise that set a collagist apart from other software assemblers centered on composition, proportion (e.g., the Golden Mean), aesthetics, efficiency (not the rabid concern with machine efficiency of C and C++ programmers ”rather, the efficiency of interaction among humans and objects, and between objects and objects), and simplicity or elegance . Not being amenable to quantification and hence formalist corruption, these skills flourished as they had in other artistic endeavors for centuries.

The basic tools of collagism were all open source, free to anyone to use and modify. Collagists made money doing what anyone could do for free simply because they had artistic skill and style. People were more than willing to pay for style, just as they did with regard to the other arts. It was a matter of prestige to have an original Jeffries payroll system, and companies were willing to pay for that prestige, just as they did for the Mattisse hanging in the lobby.

Two markets have come to thrive, side by side: Generic house-brand assemblies and designer assemblies. Users bought what they could afford and what they most needed. In many cases, generic was more than adequate, but for some highly visible (or core competency) applications, designer quality was required ”and paid for.

Aspiring collagists shunned software education offered by traditional departments and universities (even when they stopped calling themselves software engineering programs) in favor of apprenticeship programs located in liberal arts colleges.

Objectionary objects turned out to be self-modifiable. A key idea ”self-evaluating rules ”was the only prerequisite. Rules can be recursively defined and can be modified simply by adding, deleting, or reordering the member objects. Self-evaluating rules are well suited for use as genetic algorithms. Shortly after the release of the Objectionary, various assembly hackers noticed this fact and took advantage of it to create objects that reconfigured themselves as a function of the environment in which they operated.

The earliest self-modifying software consisted of nothing more than complex rules that evaluated to some result that could be subjected to a fitness test. Later attempts allowed participation of all sorts of objects, applications (as it were) that were free to modify the collection of participating objects, the script object that coordinated the interaction of the objects in that collection, and the rules contained within each object that constrained or enhanced its individual behavior.

An interesting story, or a plan of action for Object Thinkers and Xgilistas?