I just ran across an article by Steven G. Bloom about Iowa and how it is ridiculous for it to play such an influencial part in picking a president.  There have been a lot of articles by Iowans saying how inaccurate the article is.  But they don't actually address the main point in his article, that Iowa is very different from the rest of the country and that it should not be so influencial in choosing a president.  So, what states are typical?  Does he think that California is it?  New York?  I lived in upstate New York for seven years, but have never lived in California.  However, it seems to me that most people outside of New York or California do not think of either of them as typical.

I live in Illinois.  Illinois has two parts, Chicago and "down state".  Down state has some decent sized cities; Peoria, Springfield, Champaign-Urbana (where I am from), Bloomington-Normal.   But down state is pretty similar to Iowa.  The biggest difference between the states other than Illinios having Chicago is that Iowa has way better politicians.  Like nearly every other state.  (Sigh!)

Indiana is to our east.   In spite of Indianapolis, it is a lot like Iowa, too.  Ohio has a bunch of big cities, but in between them it is a lot like Iowa.  Wisconsin, Minnesota, North and South Dakota, Oklahoma, Nebrasks, Missouri.  Even western Pennsylvania.  My daughter lived in Kentucky for awhile, and it isn't that different.   The rural south is different in some ways from the rural midwest.  Rural Mississippi is heavily black, for example.  But they like to hunt and are more religious than average for Americans, two of the prominent features of Bloom's Iowa.  Rural people in Texas and Colorado are more likely to own horses than hunting dogs, but the spirit of rural people is pretty similar around the country.

The red vs. blue divide in the US is mostly rural versus urban.  It is pretty evenly divided, which is why there is so much political struggle.

I claim that Bloom's main point is wrong.  Iowa is typical.  The fact that Bloom can say that means he hasn't much of an idea of what the US is like.  I'd still like to know what he thinks is typical.  I think it would be illuminating.

A story of open source before open source was cool.    Agile development in the 70s.  How VistA helped the VA provide the "best health care anywhere". That is a talk at OSCON, by the way. 

One of Christopher Alexanders underappreciated ideas is that of a pattern sequence.   A pattern sequence is a set of patterns that are often applied in a particular sequence, a "pattern of patterns", as it were. 

James Coplien has been trying to promote the idea of pattern sequences for some time.  He and Neil Harrison wrote a very short paper about them and he wrote a longer paper with Ronald Porter and Tiffany Winn.  Although I haven't written much about sequences, I agree that they are important.  Kent Beck and I wrote a paper on the patterns behind HotDraw some years ago that was called Patterns Generate Architectures.  It shows a pattern sequence that produces a graphical drawing editor.  We had hoped at the time that other people would describe their designs as sequences of patterns, and a few people did, but not as many people as I wish.

I have been thinking about pattern sequences recently as a way of organizing design patterns.   In particular, I think the "creational patterns" from Design Patterns show several simple pattern sequences.  The first step of these is always Factory Method, which can then be followed by either Abstract Factory, Builder or Prototype.   Abstract Factory and Builder can be combined; either a design with Abstract Factory can be replaced with one with Builder, or (as the book says) a Builder can be implemented with an Abstract Factory.  The book says a builder can be implemented with Prototype, which is plausible, but I don't remember ever seeing one in the wild.  So, the standard sequences are Factory Method followed by Abtract Factory and then Builder,  Factory Method followed by Builder, and Factory Method followed by Prototype.

Factory Method is such a trivial pattern that sometimes I wonder why we put it in the book.  It is basically the same as Template Method, but seen from the point of view of the method that the template method calls.  However, the fact that it is the start of these (very short) pattern sequences makes it much more interesting.  So, I have decided that I am happy including it with the others.

The point of Factory Method is to avoid hard-coding class names when you are constructing objects.   Instead of saying "upButton := Button new" you should say "upButton := self createButton" and hide the reference to the Button class in the createButton method.   The advantage of Factory Method comes when you want to change the class of buttons.  You can make a subclass of whatever is making the buttons and override the createButton method.  On the other hand, if you never need to change the class of your buttons then it is pointless to use Factory Method.  Moreover, if you have to change the class of your buttons too often then Factory Method is also a bad idea, because it leads you to make too many subclasses.   So, I tend to start with a design in which class names for constructing objects are hard-coded.  The first time I want to change them, I change the design to use Factory Method.  If I see that I am building a lot of subclasses, I switch to one of the other patterns.

One of the other patterns that I often use in Smalltalk is to use a class as a factory and to pass it in to the object that is creating instances.   I call this a "Factory Object" pattern, with the class as a factory.    But if I want a single object to create a lot of different kinds of objects (as would happen if my application needed not only to change the class of Button but also of TextField and DropDownSelection and RadioButton and ...) then I'd use Abtract Factory, which I think of as another special case of Factory Object.   It is easy to convert a design that uses Factory Method into a design that used Abstract Factory; just move all the individual "create" methods into an instance of a new factory class, and then pass the factory into the object that needs objects to be created.   If you use Abstract Factory then the object doing the creating will work with a factory and an object to be created.   But if you shift that design to Builder then the object doing the creating will work only with a builder; the builder will hide the object being created until the object is finished. Builder is another kind of "factory object".   And Prototype is a fourth kind of factory object, one in which you can use any instance as a factory for more instances by asking it to clone itself.    But in all cases, a factory object is a little more complex and powerful than factory method, and you should only suffer the extra complexity if you really need the power.

What other pattern sequences do you use a lot?  Do you know of papers that describe systems as a sequence of patterns?

Tom Munnecke posted a video of conversation we had about refactoring, design, and VistA.  I agreed with most of what he had to say, but at the time of the conversation I was uncomfortable about what he said about decomposition and how he used the story of the blind men and the elephant.  If you don't know that story, see the poem that introduced it to the west, or the Wikipedia article. I use the story when I teach OO programming.   I give three different views of OO programming, and say that they are all true, but each view is limited.  OO is a culture, and no description of a culture can be complete.

Science (and western thought in general) is based on reductionism, on making models, on abstracting.  It is a very powerful tool.  But patterns are very much about balancing forces, about appreciating the disadvantages of a technique as well as the advantages.  The story of the blind men and the elephant is useful because it warns us of the dangers of reductionism.  The story seems to have been told originally to warn against religious claims to exclusive truth.  But Tom used it (and I do too) against a more broader narrow-mindedness.

Most people do not want to be narrow-minded.  We want to be "right-minded", i.e. to see things correctly.  When you tell someone they are narrow minded, they tend to get mad at you.   But if you say "you are forgetting this part of the problem" then they are more likely to actually think about it.  They might end up agreeing or disagreeing, but they will at least talk about it with you.  We all know it is easy to miss things, that we only see part of the situation.  

One of Tom's metaphores is a cat; once you disect a cat then you can't put it together again.  It is not a good metaphore for understanding, because we could draw blood samples from a cat or take X-rays of it without killing it.  Blood samples are only a tiny part of a cat, and only show us a fraction of what it is, but sometimes a veterinarian can learn something important that way.  However, it is a great metaphore about making changes to a system.

I think that Tom uses the cat metaphore because he is concerned that the VA has made large changes to VistA without understanding it, and these changes involve cutting out parts of it without realizing that the parts that are cut out are deeply connected to the others.   From talking with him, I can see three things that he thinks people have ignored.

1) Tom sees VistA as much more than just a piece of software.  VistA is a community, a process for working with the software, a knowledge base.  One of his original purposes of building VistA was to create a community, and he not only succeeded but is proud of how he succeeded.  So, it pains him to see people try to reuse the software but at the same time ignore the community, and perhaps even supress it.  

2) VistA was developed in a bottom-up fashion.  Each hospital had a few programmers, and each programmer worked closely with doctors.  There was no overall architect or plan, other than improving the health of veterans.  This process undoubtedly had some weaknesses, but it had tremendous benefits, as well.  It resulted in a system that fits the needs of doctors.  It is a major reason why VistA has been so successful, and the VA has worked hard for 15 years to try to have a more top-down development style, and has been impressively unsuccessful.

3) VistA is driven by metadata.  Metadata means different things to different people, and VistA has a variety of kinds of metadata.  Sometimes it means the data that indicates the provenance of the real data, and VistA has that.  But the kind that interests me the most and that I think interests Tom the most is configuration data that controls the behavior of the system.  Most hospitals that use VistA have a cadre of medical experts (usually trained as doctors or nurses) who configure VistA.  Most of the work of configuring VistA to a hospital does not require programming in Mumps, but just changing the metadata.   This means that the details of VistA are under the control of medical experts (who have to become VistA experts before they can exert this control) and not programmers.   Tom thinks that VistA should have a lot more metadata, and that there are a variety of things in VistA that now require programming that ought to be done by the experts who configure metadata.

These three aspects of VistA (and I expect there are more; these are just the three I can recognize) contribute to making VistA such a good fit for healthcare.  Healthcare varies enormously, and it is hard for one piece of software to fit everywhere.  The second and third aspects are part of what makes VistA so configurable; the first aspect helps people to learn how to configure it.

This description of VistA is just the parts of the elephant that I have felt.  It is a complex system and perhaps is not knowable by any single person, no more than a city can be completely known or the internet can be known.  Nevertheless, I know Champaign pretty well and I know Chicago better than I know New York City, though I know New York City better now than I did a year ago.  I look forward to getting to know VistA better.

This is a PhD thesis on applying design patterns (among other things) to building Technology Enhanced Mathematics Education, i.e. computer systems for helping teach mathematics.  These patterns are more closely related to "pedagogical patterns" than to software design patterns, but the thesis is probably interesting to others doing research in patterns.

http://www.yishaymor.org/phd

I remember a bit of excitement about Naked Objects a few years ago, and I thought it was a promising approach.  I haven't heard much recently, and wondered what had happened to it.

Check out the 2004 PhD thesis by Richard Pawson, which is easier to read than most theses.  I think it is an important idea.  The goal is making it easier to get to the heart of the users problem domain, and to be less distracted by technical frameworks.

And now the Naked Objects has become an Apache project!

It will be good to see people use this more.

I just found a good article on what makes VistA good.  VistA was developed in the 70s and 80s using an open source development model.   In the last two decades, the VA has often tried to develop it using a more commercial top-down model, and has repeatedly failed.  What makes VistA good is that programmers pair-program with clinicians.  They work closely to make sure that the system does exactly what the hospital needs.  That is the process that led to a system that has won all kinds of awards, and it is not an accident.

I'm spending the summer in New York (Westchester county) working on a framework for business transaction processing.  Well, I'm really working to help bring "Liquidity Manager" to the point where we can try it out on the first customer, but that is the same thing.  The company is called "Metaficient" and it is a typical startup with a few smart and dedicated people working hard to bring their first product to market.  It is fun.  The hardest part for me is being away from home for so long, but my son Caleb is out here with me, sort of bringing a piece of home with me.

The point of this note is to let people in NY know that I am here.  About a year ago I exchanged e-mail with someone about contacting him if I came out this way, but I can't find it now.  I recall he read my blog.  And there are probably lots of people out here that I know.  I've got a lot to do this summer, but I wouldn't mind getting away every now and then to talk to interesting people.