Why a reluctant coder chooses OpenACS app framework library

image of International Space Station

ISS is made of repurposed parts. Image in public domain by NASA

Why a reluctant coder chooses OpenACS app framework library

This post is a continuation of a series on critical reviews by coders of OpenACS. And, what it means as a reluctant coder.

 

Review: Code quality varies. Some apps are poorly designed, written and untested.

As a reluctant coder, this indicates that the project is working and the culture is open to new things. It’s the nature of a healthy open source community to accept code in early development or when poorly written.  If the package is useful or inspires, the package will be improved or a new one made to replace it.

 

Review: Apps are monolithic ie not re-usable per Glass’ Fact 16, therefore OpenACS’ packages are not reusable:

Fact 16: “Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.”[Glass]

Is there still hope for a reluctant coder to reuse OpenACS code in the wild?

Yes. Consider Glass’ Fact 16 in context of some of Glass’ other facts. They create a useful systems paradigm. The paradigm helps to know when to build, and when to use other code (aka Cost-Benefit Analysis):

“Fact 17: Reuse-in-the-large works best in families of related systems and thus is domain-dependent. This narrows the potential applicability of reuse-in-the-large.”

“Fact 18: There are two ‘rules of three’ in reuse:

  1. It is three times as difficult to build reusable components as single use components, and
  2. a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.”[Glass]

“Fact 19: Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.”[Glass]

“Fact 20: Design pattern reuse is one solution to the problems inherent in code reuse.. ..Design patterns emerge from practice, not from theory.”[Glass]  In my own experience, the process of converting an expert system to a software system is an iterative one based on experience. An expert system is not made by following a map of predetermined logic and workflow or other intellectualized system.


Glass, Robert L. “Facts of Software Engineering Management” Sample chapter Nov 22, 2002. why people are important, technical hype does more harm than good, and complexity is, well, complex. From http://www.informit.com/articles/printerfriendly/30091