Some reference information: Patterns, Refactoring, and Dynamic languages

I just thought I'd throw out some titles of the books I've been reading.  These are mostly to catch up on conversations I've been having with Ralph Johnson (who wrote the first paper on refactoring) and Ward Cunningham, another ubergeek.  There is a cluster of activity/thinking around the notions of refactoring, pattern languages, open systems, and dynamic languages (Smalltalk, in particular).

Design Patterns, Elements of Reusable Object-Oriented Software  by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the "gang of 4") has sold over 500,000 copies in 13 languages and is a classic in the field.  What I really like about patterns is their ability to represent abstract thoughts and communicate these effectively.  The "Interpreter" pattern gives us: "Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in a language."  This gives use some tools for talking about the dynamic nature of language, and perhaps an intellectual tool for wrapping the MUMPS language in some way.  I wrote about patterns as part of a vision of VA Future IT architectures.   Patterns also give us a tool for talking about organizational transformation triggered by the software...  a key aspect of the success of VistA.

Analysis Pattern Reusable Object Models, Martin Fowler.  Fowler is an object-orientation and pattern guru; he uses some examples from health care.  It is also an interesting case study on the notion of abstraction level - at what level of abstraction do we look at a system?  Do we look at a system as just a collection of interfaces, or are there broader, more general patterns to be examined?  He gives the example of analyzing an address book, which may contain entries for people as well as companies.  He shows how the system can be generalized around the concept of an abstraction called "party" - which could be either an organization or a person.

Domain-Specific Languages, Martin Fowler and Rebecca Parsons: an interesting discussion of this linguistic tool.  I am interested in this notion both from an internal perspective - viewing the core kernel as an instance of a VistA "virtual machine," as well as creating a DSL for clinical applications, semantic processing, and the like.

Innovation Happens Elsewhere, Ron Goldman and Richard Gabriel.  A great introduction to the open source model.  A bit dated (Wikipedia was a novelty back then), but a wonderful collection of insights into open source communities.

 

 

Comments

vancurtis

Some Other Resources

Hi Mr. Munnecke,

I enjoyed your dinner conversation video. Some other references I recommend to folks in this general problem space are:

 * "Refactoring: Improving Designs of Existing Code" by Martin Fowler. Even though it's written in Java, I like the systematic approach to improvement via small controlled changes a lot. It may even suggest another approach to refactoring other than deconstructing the VistA elephant.

 

 * "The New Methodology" by Martin Fowler. (http://martinfowler.com/articles/newMethodology.html) OK, I'm a Martin Fowler fan boy, but this gives an interesting perspective about building software vs building buildings, and turns a lot of traditional project management assumptions on their heads.

 

 * "The Cathedral and the Bazaar" by Eric Steven Raymond. (http://www.catb.org/~esr/writings/homesteading/cathedral-bazaar/) Gave me insight into how thousands of unorganized open source contributors can be more productive than traditionally organized development teams and how contributions can be weighed on the merit of the contribution, not who contributed it.

I'd like to know how many bottles later you all figured out the solution to the problem of refactoring VistA ;-)

Tom Munnecke

yes, Fowler is spot-on

 

Yes, you are tapping into a very rich vein of thought... I hope that folks listen to it.

One of the criticisms of the early VistA approach by the centralists (the Office of Data Management and Technology - we called them "O Damit") was that it would result in "helter skelter" development.  Yet we produced a consistently integrated, evolutionary collection of packages that attracted thousands of people to contribute at many different levels - mostly for free.  The softwre that ODMT produced was all stovepiped, none of which talked to each other.  But they critcized our development approach (the "Bazaar" model in Raymond's paper)

re: how many bottles of wine in Ward's kitchen necessary to solve the refactoring problem: I would refer you to another software guru Frederick Brooks, who in Mythical Man-Month wrote: "Nine Women can't make a baby in one month."   Translated, that means that 9 bottles of wine over 9 dinner conversations is much more productive than 9 bottles in one night :)  So, we have a few more bottles to go before we solve the problem.

More from Fowler http://martinfowler.com/articles/newMethodology.html on the New Methodology:

"But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption."  

lots of interesting material out there http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development 

I did not find any theory to account for the high success rate of lightweight, low-ceremony methodologies, the low success of very-high-ceremony methodologies... I finally concluded that there is something there, in front of us all the time, which we are not seeing: people. People’s characteristics are a first-order success driver, not a second-order one. In fact, I have reversed the order, and now consider process factors to be second-order issues.

Most of my experiences can be accounted for from just a few characteristics of people. Applying these on recent projects, I have had much greater success at predicting results and making successful recommendations. I believe the time has come to, formally and officially, put a research emphasis on “what are the characteristics of people that affect software development, and what are their implications on methodology design?”