I have been reading James Shore's weblog for some time now. He discusses all aspects of Agile software development practices. My main agile focus is testing, during design and development, but recently I found another interesting idea in a draft book chapter called Single Code Base. The idea of single code base is keeping all your clients on the same code. The exact same code, no branches in your version control repository. Most of us will find this a surpising suggestion, but it does make sense if you can possibly accomplish it. Imagine not figuring out which code can be shared between projects, and imagine not merging code between projects, or merging it back into OpenACS itself. If OpenACS was more flexible it might even be possible to run client projects with the official OpenACS or .LRN code base. How could we make this possible? What features does OpenACS need to make this type of reusability a reality? Recently in IRC Don Baccus suggested that package inheritance would improve reusability. I'd like to explore that idea more. I guess it would involve allowing a certain package to provide an optional user interface, or extended features built onto a base package. Right now the worst example of the failure of reusability is file-storage. It has everthing, including the kitchen sink, tacked onto its feature set, making the user interface confusing and the code difficult to maintain. We could imagine a simplified folder/file browser that provided the basic tools to build a file-storage like package, without all the overhead. Of course, over the years we have improved the focus of the toolkit and defined some best practices for how to use the features of the toolkit that did not exist when file-storage was originally developed. Now that we have learned from the history of OpenACS is a good time to improve it. The other major feature OpenACS needs for reusability is theming. That is, a way to package up the look and feel of an OpenACS install. Improved use of CSS and standardized CSS classes and ids would improve reusability, not to mention usability of the applications built on the toolkit. Putting all the CSS, icons and other design resources in one place, that can easily be overidden with local modificaitons without rewriting the application packges would make out-of-the-box installation of a new look and feel much simpler. Even if we never get to a single code base for every OpenACS/.LRN project, working towards that goal can only improve the adoption of OpenACS/.LRN and focus developer effort on improved applications instead of working around the limitations of reusability. (Edited for typos 2006-09-06)

View full post