28 Jun 2005
Yes, this has an RSS feed
Thanks to Ben Brophy for helping improve it.23 Jun 2005
Harrison Bergeron Today
Actually, for the last decade or more. This is an old story, happened maybe 10 years ago, when pagers were common but cellphones were not. But since I'm blogging now, I thought I'd record it here.
In "Harrison Bergeron", a short story by Kurt Vonnegut, equality was achieved by supplying handicaps to people: beautiful people got masks, strong people got weights, and smart people got radios which randomly made noise to disrupt their thoughts.
I was reminded of this story when I was standing in a small group at work discussing a problem we were having, when the pager of one of my coworkers went off when he was in mid sentence. He looked at it to check the message, then looked up and said "now, what was I talking about?"
20 Jun 2005
Beaver progamming
Memorial day weekend I was with my family, and watched educational TV with my nieces and nephews. One show was about Beavers and how they live. Beavers. "Nature's engineers."
And it struck me that Beaver engineering has the same relationship
to real engineering that 'software engineering' does.
The analogy is
perfect.
Contrary to countless cartoons in alumni magazines of engineering schools of beavers wearing hard hats and looking at blueprints, beavers don't actually plan.
They know how to manipulate wood and branches and sticks and mud.
They start with a general idea of where a dam should go, they then put logs and sticks in place with no calculation or forethought.
Once it's starting to hold water, their prime instinct kicks in: they are sensitive to the sound of running water.
Wherever they hear a leak, they throw more sticks at it and apply a patch.
Once there are few enough leaks, they decide they're done.
Things that are valuable
Things that are valuable:
- user's data and documents
- user's experience
- user's time
- user's satisfaction
Things that are expensive:
- Bugs, especially when found by an end-user
- Quality Assurance
- Documentation
- Training
- User support
Platform or Product?
As stated, this is like asking "engine or car?" The product has to have a platform. The question is "is there a defined product?" and separately "what are the capabilities of the platform?"
Product
There will be a product, at least at many institutions. The product will be a configuration of tools which have been tested and documented and offered to their community.
The question is then: is there a central effort to provide the testing and documentation of a defined set of tools?
17 Jun 2005
"Enterprise"
One term people use which needs more consideration is "enterprise." Sakai is supposed to be suitable for enterprise use, and feature enterprise integration.
In this context, for most people "enterprise" does not involve going boldly where no one has gone before. Indeed, it means the opposite: being safe, reliable, providing the base from which careful exploration can occur without worrying about the infrastructure.
"Enterprise" often means "enterprise scalability." Can it scale up to be used by large institutions, large numbers of users? Sometimes "affordably" enters into this consideration, but generally it's limited to a relatively objective consideration of potential bottlenecks preventing adding additional hardware as needed, or UI issues where it's assumed that there will be a small number of students or courses to be listed. Enterprise scalability is relatively easy to determine and achieve, and as hardware power increases, it gets easier and easier.
What I'm worried about may be thought of as "enterprise supportability." This is more difficult to evaluate, but is critical to me. I have a relatively small- to medium-sized user base, and could support it all on one medium-sized server without anything fancy in the code. But, I have a very fussy and demanding user community, and a very small and thin-skinned staff providing support. For enterprise supportability, quality assurance, easy-to-use and natural UI, and documentation are key.
Moodle and LAMP in general can work on enterprise scales. But where PHP and Perl fall behind Java is in Enterprise supportability and sustainability.
A digression. Some observations from Baltimore relate to this. I visited the submarine in the harbor, the Torsk. It was built during World War Two, under some time pressure, but it still was good enough that it was still in useful service twenty years later. It still had much of the original equipment, though some had been upgraded over the years. What does it take to achieve that, and how can software reach the same level of quality and stability?
I also watched TV in my hotel room, and as often while I'm traveling, I wind up seeing shows on National Geographic or History Channel about transportation disasters. Ones I saw this trip focused on reconstruction of the disaster, finding out what lead to it so that it could be avoided in the future. In each case, they were able to examine detailed records of where each wheel or propeller came from, when it had last been inspected, how it had been treated, etc.
In the physical world, we can often buy things which are consumer grade, commercial grade, or military spec. We should think of software in the same way.
You probably don't have blueprints to your house, and you've probably lost most of the manuals to the things in your house. That's OK, you're unlikely to need them in a hurry if at all. You have learned the quirks of your house and may be responsible for many of them. You have the freedom to poke holes in walls and add doors, limited only by local building codes. But those building codes reflect the experience of years, and of things which went wrong and resulted in damage, injury, or death and following them is a good idea.
But your office building does have records and blueprints and manuals. The stakes are higher, and information needs to be available quickly to anyone who needs it, not embodied in an individual's experience.
In transportation, military, and space, regulations require careful tracking and record keeping, in some cases tracking the origin of every nut and bolt. This increases costs, but is justified by the huge cost of a failure.
This is how we wind up with "$600.00 toilet seats." Being careful, planning ahead, checking quality, and keeping accurate documentation are expensive in labor and elapsed time.
For "Enterprise supportable" software, we need to pay attention to documentation of all interfaces, decisions, bugs reported and fixes made. Brian Behlendorf emphasized this in his talk as "transparency" and keeping archives of emailing list discussions which can be referred to later. The use of bug tracking systems such as Bugzilla and Jira are key to keeping the bug system transparent.
A component of "enterprise supportability" is "sustainability." For it to be sustainable, the interfaces must be stable, knowledge must be shared by many developers and the code and interfaces must be documented well enough for new developers to work with easily. Data formats must be designed for extendibility and/or use well-tested and widespread standards.
For "enterprise integration", APIs must be well defined and complete, so that implementations of these which hook in to the disparate systems across the institution can be developed and tested, and that investment can be paid off over several years.
We must recognize that these requirements are expensive, and slow development in the short term. But they avoid problems in the long term. The need to document, train support staff, and educate end users slows change, but is unavoidable for such enterprise deployments. Often I've had to delay what is a trivial code change, because there would not be time to test, document, and retrain.
But, some installations are not such enterprise installations. They are small-scale, intended to be development or experimental environments, or there are lower user expectations or sufficient documentation, support, and training resources to allow more flexibility. We need to provide a very flexible and complete platform for these uses. But it must be done in a way which also allows for the enterprise sustainable version.
This is not in conflict with open source development. Well-run open source projects prize documented code, adherence to group coding standards, record keeping, and general transparency. They use modularity and unit tests and automated QA as much as possible, so that any human labor intensive testing is minimized. They avoid having too much information undocumented and in the minds of too few people.
Where there is conflict is in the area of stability and uniformity vs. rapid change and experimentation.
Sakai needs to support both. It needs to encourage experimentation and provide a basic framework which enforces as little as possible. I think the core framework should not even require that tools be written in Java.
The key is to make the status of each component and tool clear to everyone: reviewers of Sakai, system integrators, and end users. They need to know what things are stable, tested, and enterprise-ready; what things are approaching stability and ready for pilots; and what things are cutting-edge experiments.
The "bundle" should be "enterprise supportable", but there needs to be space for the development and distribution of pilot and experimental contributions.
