2016 - 2017 short talks and presentations


Conrad Weisert is a frequent speaker at professional society meetings, user group meetings, and trade shows. These presentations take between 45 and 90 minutes, depending on audience participation.

Topics in demand in 2016 for general/technical audiences include these:

Mainly technical topics

Mainly managerial topics

Design patterns for computation—exploiting numeric objects and type safety (based on the book) UML: "Unified Modeling" or "Unstructured Muddling" Language?
Elementary objects—the rest of the story The Participative Approach to Methodology Development and Dissemination
The Elusive Person Class—Clearing up misconceptions about a very common composite class The Collapse and Rebirth of Information Systems Infrastructure -- ACM Chicago Chapter meeting January, 2001
Pseudo-classes, Quasi-Classes, and Object-oriented Fiascos The Role of a Phased Life-Cycle in Object-Oriented Software Development: and vice versa.
Tutorial: Java for computation -- Making the best of a Java weakness. Reusable components: Will object-oriented technology finally break down the barriers?
A Look at Program Quality—Not just absence of errors.

Survey topics

New in 2016!   Avoiding the Quasi-Elementary-Type Trap—Are string and decimal data bona fide objects? Forty Years of Major Dramatic Breakthroughs in Software Development Methodology
- Legacy Systems of the Past, Present, and Future

Also see some of IDI's single-session courses. For information about other topics, call (1-773) 736-9661 or E-mail cweisert@acm.org.


The Role of a Phased Life-Cycle in Object-Oriented Software development and vice-versa

A few years ago nearly everyone agreed on the wisdom of planning and contolling a major software development project as a sequence of discrete phases. At the end of each phase the project team produces a set of results or deliverables, which form a basis for both:

Today, the status of a formal phased life cycle is uncertain and surprisingly controversial. To minimize risk of failure today's major software development project needs a modern life cycle methodology -- one that is:

Is such a modern and enlightened life-cycle feasible? If so, how do we integrate it with our other methodology components, in particular with

What organizational infrastructure is required to make it all work? What skills will our professional staffs need, and how can they acquire those skills? Is object-oriented analysis a sufficiently mature discipline to drive the early phases? Is there really such a thing as the waterfall approach?

Return to top of short talks description.
Return to IDI home page


Reusable components: Will object-oriented technology finally break down the barriers?

"A software development organization drawing on mature libraries of subroutines, macros, data structures, and other packaged components can enjoy huge advantages in the productivity and manageability of its projects and in the reliability and maintainability of its end products. Indeed of all the tools and techniques of a modern development methodology, the heavy use of existing modules offers by far the greatest benefits. So far, however, only a minority of organizations are routinely exploiting those benefits. "

That paragraph was written in 1975. At that time the structured revolution was to be the key to the long-overdue taming of reuse especially in business applications.

It could have been written again in 1995. Now object-oriented technology was going to give us easy reuse. Most of us are still waiting.

What accounts for these repeated disappointments? Is the concept of reuse somehow flawed? Does reuse not lend itself to today's applications and platforms? Is reuse sound in theory but too hard to set up and manage? Are today's languages and tools so powerful that repeated redevelopment has become easier and cheaper than tracking down and incorporating an existing solution? Are today's managers so hopelessly undisciplined that any systematic approach is doomed? Do contract development firms deliberately reject reuse so as to inflate their billings? Should we give up, or are we now on the threshhold of the long-awaited breakthrough?

Conrad Weisert will put forth his own explanations and offer practical advice on how to exploit this promising but elusive approach, both with and without object-oriented technology.

Return to top of short talks description.
Return to IDI home page


The Elusive PERSON Class

Many applications trying to exploit object-oriented technology include Person objects among their central data items. Indeed, a Person class is often used as an early example in OOP courses and textbooks. But it's also one of the most troublesome application-domain classes to get right, and projects are littered with the incomplete and inconsistent remains of flawed attempts.

Some disillusioned experts now claim that a non-trivial general Person class supporting a full range of applications is impossible and advise us not to bother trying. "You can't define a Person class until you know what the application is," was the warning put forth at a meeting last year.

Some of the questions that arise in designing a Person class are:

Conrad Weisert will offer his views on those and other issues, and will show C++ or C# examples.

Return to top of short talks description.
Return to IDI home page


The Paricipative Approach to Methodology Development and Dissemination

Once an organization makes a commitment to disciplined software development, it faces choices in how to choose its best practices and how to communicate those choices to its professional staff. Two common approaches that rarely if ever work well are:

Instead experience in both large and small organizations confirms the effectiveness of a high degree of participation by the professional staff in all phases of methodology administration. The participative approach works especially well in a decentralized organization that allows its individual areas a great deal of autonomy in customizing their methods. Conrad Weisert will describe the organizational and documentation infrastructures for methodology administration, and will examine the costs and the human factors.

See related article Methodology Development and Dissemination in a Decentralized Organization.

Return to top of short talks description.
Return to IDI home page


♦♦♦ Object-Oriented Design Patterns for Computation    

Most textbooks and courses on object-oriented programming (OOP) emphasize three kinds of object:

The object paradigm, however, is often ignored or misused for numeric computation. Surpsisingly many programmers are developing Fortran programs in Java or other OOP languages. But OOP is extremely valuable—some say necessary— in computing with numeric quantities, where carefully designed numeric classes:

Conrad Weisert will show not only how numeric objects simplify computational programming, but also how common design patterns can simplify the creation of robust numeric classes themselves. He will draw on C++ examples from both business/commercial applications and scientific/engineering applications. Knowledge of C++ or Java is helpful but not required.

Also see this related book.

Return to top of short talks description.
Return to IDI home page


Elementary Objects: the rest of the story

In the above presentation we explored numeric objects, but they aren't the only elementary data items that should be treated as objects. Object technology offers strong support for both text and discrete data items, avoiding many bugs and facilitating future maintenance of application programs.

Return to top of short talks description.
Return to IDI home page


Java for Computation
Making the best of Java's weakest area

Despite Java's many attractive qualities, knowledgeable programmers realize that it's badly suited to numeric computation, for two reasons:

These obstacles affect both business applications and engineering/ scientific applications. We can't do much about the performance obstacle, which will become less important anyway with the continuing improvements in JIT compilers. Of greater interest to the object-oriented designer is how to circumvent the second obstacle to write robust, maintainable, and understandable programs that do non-trivial computation.

Conrad Weisert will discuss the general area of elementary numeric classes, with particular emphasis on a proposed way of circumventing the operator overloading problem. His talk combines elements of these articles found on this web site:

Return to top of short talks description.
Return to IDI home page


UML: "Unified Modeling" or
"Unstructured Muddling" Language?

The UML is enjoying growing acceptance among I.S. professionals as the preferred set of tools for "analysis and design". It is being endorsed and publicized by leading writers and teachers. It has been blessed as a standard for system modeling by the Object Management Group (OMG). It is assumed to fit especially well with object-oriented techniques.

Therefore, any organization involved with systems analysis must recognize the importance of UML and choose:

  1. to embrace it as the main components of its systems analysis methodology,
  2. to reject it in favor of some well-defined practical alternative, or
  3. to integrate selectively the UML's best features into an established mainstream systems analysis methodology.

Packaged with the UML are two non-object-oriented methodology components: use cases and the so-called "Unified Process" life cycle.

Conrad Weisert will examine critically the strengths and weaknesses of UML in comparison with other approaches to systems analysis, emphasizing its suitability for capturing and organizing user requirements and documenting a rigorous system specification. He will offer guidelines for making choices.

Return to top of short talks description.
Return to IDI home page


Pseudo-classes, Quasi-Classes, and Object-oriented Fiascos

Segments of the so-called "object-oriented community" have given rise to a lot of folklore, circulating proposed standards and techniques that are actually extremely harmful. In one organization after another, very large project teams working on major applications have gotten bogged down in massive cost overruns and schedule slippages that ultimately served to discredit object technology in their organizations. In many such fiascos, the project team had attempted to follow ill-advised "standards" recommended by some presumed expert.

Conrad Weisert will describe several of these harmful techniques, analyze their impact on software reliability and maintainability, and suggest alternative approaches.

See related article Pseudo Classes and Quasi Classes Confuse Object-Oriented Programming

Return to top of short talks description.
Return to IDI home page


A Look at Program Quality

NOTE: This 90-minute presentation is an effective guest lecture in a full-term programming course at the advanced undergraduate level.

Although we thought that many issues of program quality had been settled in the "structured revolution" of the 1970's, we still encounter just as many atrocious programs as ever. Some of the worst come from leading software vendors! Organizations are finding that their multi-tiered object-oriented applications, like the 10000 statement monolithic spaghetti code of a generation ago, are turning out to be costly and painful maintenance nightmares.

We begin by asking: "What is a good program?" With the participants help we develop a list of criteria, both easy-to-measure (objective) and hard-to-measure (subjective), pointing out that the more subjective harder-to-measure criteria have the biggest impact on flexibility, maintainability, and reliability.

We explore two broad areas in depth, illustrating both with good and bad examples:

Return to top of short talks description.
Return to IDI home page


Legacy Systems of the Past, Present, and Future

We generally associate the designation "legacy system" with the most inflexible and unmaintainable sort of application developed by the most unenlightened programmers for an obsolete mainframe computer. Today, however, despite decades of dramatic breakthroughs in software development methodologies, many organizations are surprised and disappointed to discover that they have replaced those old applications with expensive new ones that are just as costly to maintain. We're still developing legacy applications!

Responsibility for this alarming situation is shared by software vendors, academic programs, fad methodologists, and contract development firms. Fortunately, a remedy is still well within the reach of disciplined management in user organizations.

Return to top of short talks description.
Return to IDI home page


Forty Years of Major Dramatic Breakthroughs in Software Development Methodology

Every three or four years someone announces a major dramatic breakthrough (MDB) in the tools, techniques, and methodology of software development. Some of those MDBs are evolutionary, building on current methodology, while others are revolutionary, requiring a sharp break with past practice.

Each such MDB has promised a productivity improvement between 1.5X and 10X that of "traditional" approaches. If we believe those claims, then, based on the aggregate impact, we can now expect to develop and maintain software with less than 1/1000 the effort it took in 1962. But what has been the real effect of MDBs upon productivity, software quality, and the software development profession?

Return to top of short talks description.
Return to IDI home page


Avoiding the Quasi-Elementary-Type Trap

Some of the most widely used standard library classes fill roles that are closer to built-in data types than to bona fide objects. Less experienced programmers may believe that they're exploiting the object paradigm when they're really just drawing upon superficially similar language constructs.

Common misuses of popular numeric and character-string library classes undermine the object paradigm in ways that make application software less flexible and less robust than we expect from object technology. Fortunately, it's often easy to correct such misuses, once the programmer understands the OOP concept. In particular, we shall note that a surprising majority of instances of:

in application programs are missed opportunities to exploit bona fide OOP, even though they may use library classes. We shall emphasize C++ examples, but we'll also look at Java and C#.

Finally, we shall note some instances of serious misinformation in textbooks and professional web sites.

Return to top of short talks description.
Return to IDI home page


Last Updated August 12, 2016