Patching and Deployment

Vol. 3 No. 2 – March 2005

Patching and Deployment

Curmudgeon

Comments are More Important than Code

The thorough use of internal documentation is one of the most-overlooked ways of improving software quality and speeding implementation.

Comments Are More Important Than Code

The thorough use of internal documentation is one of the most-overlooked ways of improving software quality and speeding implementation.

Jef Raskin, Independent Consultant

In this essay I take what might seem a paradoxical position. I endorse the techniques that some programmers claim make code self-documenting and encourage the development of programs that do “automatic documentation.” Yet I also contend that these methods cannot provide the documentation necessary for reliable and maintainable code. They are only a rough aid, and even then help with only one or two aspects of documentation—not including the most important ones.

Enforcing excellence in documentation of code is on the frontier of unsolved problems in the management of software development. Some of the solutions seem effective, but they are not yet in the culture of programming or programming education. Rare is the programming teacher who will downgrade a properly performing program because of inadequate documentation.

by Jef Raskin

Articles

On Plug-ins and Extensible Architectures

Extensible application architectures such as Eclipse offer many advantages, but one must be careful to avoid "plug-in hell."

On Plug-ins and Extensible Architectures

Extensible application architectures such as Eclipse offer many advantages, but one must be careful to avoid “plug-in hell.”

DORIAN BIRSAN, ECLIPSE

In a world of increasingly complex computing requirements, we as software developers are continually searching for that ultimate, universal architecture that allows us to productively develop high-quality applications. This quest has led to the adoption of many new abstractions and tools. Some of the most promising recent developments are the new pure plug-in architectures.

What began as a callback mechanism to extend an application has become the very foundation of applications themselves. Plug-ins are no longer just add-ons to applications; today’s applications are made entirely of plug-ins. This field has matured quite a bit in the past few years, with significant contributions from a number of successful projects.

by Dorian Birsan

Patching the Enterprise

Organizations of all sizes are spending considerable efforts on getting patch management right - their businesses depend on it.

Patching the Enterprise

Organizations of all sizes are spending considerable efforts on getting patch management right—their businesses depend on it.

GEORGE BRANDMAN, MORGAN STANLEY

Software patch management has grown to be a business-critical issue—from both a risk and a financial management perspective. According to a recent Aberdeen Group study, corporations spent more than $2 billion in 2002 on patch management for operating systems.1 Gartner research further notes the cost of operating a well-managed PC was approximately $2,000 less annually than that of an unmanaged PC.2 You might think that with critical mass and more sophisticated tools, the management cost per endpoint in large organizations would be lower, though in reality this may not be the case. The objective of this article is to provide some rationale—drawn from enterprise experience—to put these observations into context and present some approaches that could be useful to combat that trend.

There are a few main themes worth noting. The first and probably most important is that patch management is a team effort. In a large enterprise, many departments need to work together to correctly assess and remediate software vulnerabilities through patching. Good tooling can help, but enterprises can’t succeed without establishing a well-defined process and good communications among the various teams involved.

by George Brandman

UML Fever: Diagnosis and Recovery

Acknowledgment is only the first step toward recovery from this potentially devastating affliction.
The Institute of Infectious Diseases has recently published research confirming that the many and varied strains of UML Fever continue to spread worldwide, indiscriminately infecting software analysts, engineers, and managers alike. One of the fevers most serious side effects has been observed to be a significant increase in both the cost and duration of developing software products. This increase is largely attributable to a decrease in productivity resulting from fever-stricken individuals investing time and effort in activities that are of little or no value to producing deliverable products. For example, afflictees of Open Loop Fever continue to create UML (Unified Modeling Language) diagrams for unknown stakeholders. Victims of Comfort Zone Fever remain glued in the modeling space, postponing the development of software. And those suffering from Gnats Eyebrow Fever continue creating models that glorify each and every Boolean value of prospective software implementations.

UML Fever: Diagnosis and Recovery

Acknowledgment is only the first step toward recovery from this potentially devastating affliction.

ALEX E. BELL, THE BOEING COMPANY

The Institute of Infectious Diseases has recently published research confirming that the many and varied strains of UML Fever1 continue to spread worldwide, indiscriminately infecting software analysts, engineers, and managers alike. One of the fever’s most serious side effects has been observed to be a significant increase in both the cost and duration of developing software products. This increase is largely attributable to a decrease in productivity resulting from fever-stricken individuals investing time and effort in activities that are of little or no value to producing deliverable products. For example, afflictees of Open Loop Fever continue to create UML (Unified Modeling Language) diagrams for unknown stakeholders. Victims of Comfort Zone Fever remain glued in the modeling space, postponing the development of software. And those suffering from Gnat’s Eyebrow Fever continue creating models that glorify each and every Boolean value of prospective software implementations.

Research has shown that the failure to recognize or act upon UML Fever affliction is largely the result of factors such as denial, desperation, or a poor understanding of its symptoms. One of this article’s primary objectives is to help overcome this failure by describing the fever’s most commonly observed symptoms for the purpose of facilitating its diagnosis at both individual and organizational levels. Beyond promoting recovery in those actually stricken, this article is also focused on the codependents that perpetuate UML Fever in their organizations by ignoring its symptoms and failing to take corrective action. It is important to understand that individuals in leadership positions who allow UML Fever-related atrocities to occur on their watches are equally responsible for the fever’s devastating effects as those actually stricken.

by Alex E. Bell

Understanding Software Patching

Developing and deploying patches is an increasingly important part of the software development process.

Understanding Software Patching

Developing and deploying patches is an increasingly important part of the software development process.

JOSEPH DADZIE, MICROSOFT

Software patching is an increasingly important aspect of today’s computing environment as the volume, complexity, and number of configurations under which a piece of software runs have grown considerably. Software architects and developers do everything they can to build secure, bug-free software products. To ensure quality, development teams leverage all the tools and techniques at their disposal. For example, software architects incorporate security threat models into their designs, and QA engineers develop automated test suites that include sophisticated code-defect analysis tools.

Even under ideal conditions, however, problems always arise. Most software will be used for many years in an ever-changing user environment. This can place new compatibility demands on software and introduce new security vulnerabilities not originally envisioned. Whatever their source, problems can be found in any piece of software and must be addressed with patches.

by Joseph Dadzie

Kode Vicious

Kode Vicious Reloaded

The program should be a small project, but every time I start specifying the objects and methods it seems to grow to a huge size, both in the number of lines and the size of the final program.

Kode Vicious Reloaded

A koder with attitude, KV answers your questions. Miss Manners he ain’t.

by George Neville-Neil