spencegreen.com

Re-use, or The Unknown Ideal

A recent software presentation that I saw started with an “architectural discussion.” One slide listed “Object/component-based design” as a feature, which was qualified by the usual platitudes including “Maximizes software re-use.” The slide then made the bold leap to “faster development” as the principal benefit of this “design decision.” I sighed. Two decades after “re-use” entered the technical nomenclature, the term is still misapplied. Re-use remains a misunderstood ideal with more promise than payoff.

Parnas’s 1979 paper, “Designing Software for Ease of Extension and Contraction”  responded to four common software objectives:

• Deliver a subset of a system’s features
• Add a simple feature
• Remove an un-needed feature
• Tailor the system to meet changing user requirements.

The common complaint against software here was that such ostensibly jejune objectives became intractable. Parnas began with the surprising description of programs as “abstract mathematical objects.” But mathematicians state and prove theorems, seeking generality. If a mathematician becomes aware of “a set of closely related theorems, he responds by proving a more general theorem.” A good theorem is invariant across instances. We would prefer a commutative property that applied to both addition and multiplication, for instance, over one that applied to only one or the other.

Programmers, on the other hand, respond to a minimal requirements set. Generality therefore has necessary design and construction costs, for that principal is de facto “not minimal” (A performance cost often exists, too). Further, programmers often associate generality with the absence of local invariants such as magic numbers and tight coupling. Real re-use has system-level implications, though.

Parnas suggests dogmatic use of a “uses” relationship between “components” during system specification. The “uses” relationship is of course the intellectual ancestor of composition, a tenet of OO design. Jacobsen defined composition in 1992 as structuring an object–which is a number of operations and a state–by its parts. A family, for example, could be composed of a man, woman, and child (more liberal compositions are of course possible). The “uses” relationship still exists in UML and frequently appears in object diagrams. Furthermore, “real” object-oriented languages such as Ada and Smalltalk make expression of this concept possible. Why then does re-use remain a novelty?

Two principal problems exist. Within a company, the cost of finding a general component is often high. Basic information management issues such as the absence of a centralized repository and poor internal search capabilities are obvious causes. This argument is unspecific, however. The real problem is an instance of the free-rider problem (this is especially true in contracting organizations). Projects are often unwilling to accept the costs associated with generality even in light of the utility realized by both that project and other company groups. “Re-use” therefore becomes a topic of much comment and little consequence. It costs too much.

Re-use works if it is the chief end. Four scenarios come to mind:

• Extensions–This category includes frameworks (eg, .NET, J2EE) and APIs (eg, Ruby on Rails).
• Components–UNIX-style applications that exist as input/output functions. grep is the obvious example.
• Schemas/Ontologies–Here we find XML schemas and interface standards.
• Design patterns*–Popularized by the GoF, concepts such as the Singleton have become the software equivalents of Charles Sanders Pierce’s hobby horse. One paper has shown, however, that patterns are usually mutilated in the process of instantiation, making them hard to “recover.” In other words, patterns do not possess the same order of invariance as mathematical theorems.

The OSS community has been the principal beneficiary of re-use’s promise. An OSS component must exist as an autonomous element on the Internet to gain support, therefore making generality and interoperability key considerations. The absence of formal funding also eliminates the free-riding phenomenon on the developer side.

Re-use has failed as a “silver bullet” in the software industry, and it will continue to do so.

Reflections on Interface Design

Like many programmers, I have long considered interface design an artistic activity best reserved for aesthetes who cannot design sort functions. One of my working software theories has been, “Programmers don’t design interfaces. Interface designers design interfaces.” My recent foray into graphical design has caused me to revise this axiom: “Programmers can design interfaces if they study interface design.” This is where I found myself several weeks ago.

During the first week of my research, I petitioned my manager for access to “the User.” After all, “enlightened” interface design teams pity the user, right? Not always. I spent several days building prototype screens and realized that not only did I not understand the user, but also that the user did not understand himself. My current project is a new system that will require new processes, training procedures, and internal organizations. Staffing needs are uncertain. Roles are uncertain. Even the system’s features are fluid. Therefore, “the User” does not yet exist. It occured to me that “Usage-centered design” fails in such a scenario, as observed by Don Norman:

Frustrated, I called a friend who currently studies design under Norman at Northwestern. As with most leaps into new technical fields, I found that the conventional knowledge was about a decade out of date (a revelation consistent with Steve McConnell’s assertion that software ideas take 10 years or more to percolate from academia to industry). “Activity-based” design is the new model. Activities are user objectives that consist of tasks, which are user actions. Discovering activities and tasks yields insight into the user’s ultimate goals. Good interfaces result from a comprehensive understanding of these goals.

Whether “activity-based” design will survive The Next Big Thing remains unclear. The approach has intuitive merits, for Norman rightly observes that useful tools like pens and musical instruments require educating the user. One can hardly imagine that Les Paul held user forums while developing the electric guitar (possible questionnaire: “Does this device help you shred more?”). At the same time, the concept of activities and tasks falls squarely into the faddish realm of process thinking characterized Enterprise Architecture, ERP systems, and BPM. But a processes are like algorithms, which have been studied for millenia. The salient insight is that most people don’t think in terms of algorithms, but most useful activities require them. With only a hint of elitism, I therefore suggest that interface designers first try to clearly state what needs to be done, approaching the user after the heavy intellectual lifting has been accomplished.

Interface Design Tools that I’m using now:
NickFinck wireframe stencils
UML2.0 stencils
Dimensioning stencils
The Gimp

The Critical Design Review

Over the last several days, my project has gone through the Critical Design Review (CDR) process. Although the format differed from the CDR that I had organized in February, the presentation problems, organizational needs, and technical outcomes were similar. CDRs have become a staple in most engineering organizations, and government contractors in particular must hold them.

In my experience, most project teams scramble to meet the CDR deadline, often submitting work that is incomplete or unconsidered. This circumstance harms both the team and the customer. For example, our group tried to meet a program management quota of 30 slides per person. The “fluff” did not escape the customer’s notice, damaging the team’s credibility.

Instead, I suggest that CDR teams emphasize quality over quantity and use the CDR forum to educate the customer and capture requirements. Think of the CDR in as:

• A pre-validation meeting: Demonstrate analytically the design’s compatibility with the current requirements set. Eventually, the customer will validate the code against the requirements. Show him that you have integrated all of his needs into your current design.
• A training exercise: Have you ever listened to a fellow developer describe a complicated algorithm or component? That guy is working on your system, but you don’t easily understand his approach because you aren’t familiar with his area of the code. Now think of the customer. He must digest the entire design with NO experience in any part of the system. Use the CDR to train the educate the customer, not overwhelm him. Other members of the engineering team will benefit as well, for their awareness of the system will increase.
• A requirements capture meeting: Each presenter should identify a list of design issues and requirements questions prior to the presentation. During a CDR, you have the customer’s undivided attention. Instead of lecturing him, ask him questions and make him think.
• A technical design forum: The team’s engineers should attend every CDR brief. Require them to take notes and submit evaluations. A CDR exists within the same genre as the Fagan inspection and the requirements review. Treat it with the same formality.

Below is a list of guidelines for maximizing the CDR’s benefits. Both project managers and engineers can use these suggestions, for a well-integrated team blurs the distinction between these two roles.

Planning and Preparation

• Don’t use a boilerplate checklist: A CDR’s main objectives are gathering and disseminating information. Circumstances dictate the best methods for achieving those ends. This is not brain surgery. Develop a considered approach based on the project, avoiding “Big M” methodologies.
• Emphasize quality over quantity: Don’t use slide quotas. Treat slides like money and spend them wisely.
• Use the 4-6 rule: Each slide should have between 4-6 bullets, and each bullet should have between 4-6 words. If a slide requires elaboration, talk through the slide using a whiteboard or create a handout for the audience.
• Print the Presentation: Every participant should have a bound copy of the presentation. In this way, you may include complex drawings and figures that may be difficult to read on the projector.
• Plan an internal CDR (iCDR) or “dress rehearsal”: The team should go through the entire CDR sequence together at least a week prior to the real conference. The presenters should speak as if giving the real presentation and the audience should not interrupt the talk unnecessarily. The latter observation brings us to…
• Identify a moderator: CDRs inevitably stall under the weight of digressions. Identify a moderator keep the meeting moving.
• Identify a scribe: It is too difficult to compile a piebald stack of scribbled notes after the meeting. Identify a scribe, give him a laptop, and require him to enter observations formally into Telelogic DOORS or an equivalent tool. Important comments and decisions are often lost immediately after a discussion takes place. Instead, capture all of the comments (annotating them by speaker and slide number) and present them as a “Minutes of Meeting” document to the customer.
• Assign a Master Reviewer: Select a technical leader with broad system knowledge to review all of the slides prior to the iCDR. The reviewer should eliminate redundancies, identify major themes, and resolve formatting inconsistences. The body of slides should reflect a coherent picture of the system. A single mind can evaluate the team’s work with respect to this objective.
• Detail = Credibility: Everyone knows that block diagrams, state charts, and data schemas require time and effort to develop. Include them in the presentation. Together, they show that the team is operating at a satisfactory level of precision. 
• Think about Food: Don’t order the usual corporate garbage: donuts and coffee for breakfast, sandwiches and chips for lunch, Coke in the afternoon. Set the tone for the day with food. Start the day with fresh fruit, toast and French jam, fresh juices, and smoked salmon. Stimulate the body with healthy food, then stimulate the mind with a careful presentation. Impress the customer.

Execution

• Choose good communicators: No leaning on furniture. No staring at the projector screen. Use vocal inflection. Discard nervous habits. Dress well. A CDR is not a political rally, but it is also not Thursday night at the pub.
• Use amphitheater-style seating: Ensure that audience members can talk to each other. “Lecture room” seating prohibits discussion.
• Ban Blackberries: Place a box at the door and force people to dump their weapons into it. This is a serious discussion that requires undivided attention. Distractions caused by Joe Flowingut and his HIGH PRIORITY ISSUES!!! cannot be tolerated.
• Use two projectors: Display diagrams on one projector and talking points on the other.

Post-Op

• Debrief: Hold an engineering meeting immediately after the CDR. Sluggishness usually occurs after such an ordeal. The PM should develop a near-term list of action items and assign them after the last slide is presented. Don’t wait for the final analysis before you start moving forward.
• Requirements changes: Identify them, analyze them, and present them to the customer.
• Design changes: Get the engineers working on these immediately. Impact analysis should be the first step.
• Risk assessment: Develop a risk list and use it to re-evaluate the project schedule.
• Action items: Develop a list of action items for the customer. What do you need from him? What issues must he address? Set a date for follow-up and get your questions answered while the issues still occupy his mind.

A CDR comes from the “Waterfallish” world, but it works well at the beginning of an Agile project as well. Although design work may be performed during Agile/XP iterations, architecture must necessarily come first. A raw feature set must also be developed to allocate builds and iterations. These work artifacts are obvious candidates for a CDR.

More With Less

An unattributed byline about Kurt Cobain in a recent GQ issue caught my attention for its terse description of a complex person.

A man of chronic contradictions, Kurt Cobain exuded an energy that was both savage and artistic. When Nirvana readied to play Saturday Night Live on January 11, 1992, Nevermind had reached Billboard’s number one spot, and the music world waited to meet its new 24-year-old star. He wore a Flipper T-shirt under a mold-colored cardigan and hair he’d dyed the night before with strawberry Kool-Aid. He also blew the shit out of the room with a 1965 Fender Jaguar the color of a Doberman and introduced us to a new status quo for cultural icons. Glamorous, dirty, quiet, and loud—Cobain would be dead in two years. And we’re still trying to figure him out.

The selective use of adjectives makes this article work: “savage”, “mold-colored”, “glamorous, dirty, quiet, and loud.” This is Seattle, and the apathetic movement that it spawned. Using an expletive makes the writer vulnerable to the reader’s contempt, but in this case, it seems to resonate against the grinding hum of the brown Fender. Here, the writer has sketched a book-length subject in 114 words.

Here’s the SNL performance.