"Count what is countable. Measure what is measureable. What is not measureable, make measureable." -- Galileo

Tuesday, December 23, 2008

Manual vs Automatic

One of my YouTube videos for my College of Santa Fe course in database design picked up an interesting comment the other day. The respondent said, "I'd personally never hire a DBA that lacked the ability to normalize using method #1 [manual normalization]." My answer in turn has a bearing on Zope, Plone, Python, Archetypes, and Joel Burton.

I'll admit that I've been paying my rent in large part based on the skills that I learned back in the 80s from my Oracle Masters classes on manual normalization. But today a machine can generate a model or SQL more quickly and accurately than a human.

With frameworks like Zope and Plone out there, I'd much rather have a good object-oriented person working for me. In the end, its going to be job requirements that should drive any hiring decision, not some a priori statement. One could equally say that I'd never hire a printer who couldn't illuminate a cover page by hand.

I am reminded of my graduate statistics professor (Dr. Karl, UA) who taught us this bizarre matrix method for computing the solution to ANOVA problems. Even in matrix notation, to get an exact answer, sums of squares had to be painfully cranked out on a hand calculator. And interestingly, he never asked for an exact numeric solution, only the matrix formulation.

A year later I was hired as a post-doc at the NMSU Dept. of Horticulture to do onion karyotyping and agricultural statistics. A program named SAS was used there. It only required that I put the data in a Fortran-like data file and define the problem as a matrix solution. Exactly what I was taught. I never had to manually calculate a sum of squares--the machine did all the grunt work.

What I want in a new hire is someone who understands objects conceptually and can use whatever tools are handy to generate a data model, a needed SQL statement, or a Web-enabled form that interacts with a backend database. While its handy to have a fundamental understanding of normalization, a high level of skill in manual normalization isn't usually needed.

Now in the Zope/Plone world, my webmaster (not a Python programmer at all) can build a UML model, run the ZARGO file through Joel's web tool, and unpack the archetype in the correct Plone products folder. A trivial amount of Python is all that is needed to manually change simple things like misspelled labels, incorrect widget types, and so on.

Being able to go from UML to functional Plone product so easily is one of the incredible benefits about using Plone as a CMS. Its hard to imagine how people work in SharePoint, Drupal, WordPress, or Alfresco without such a capability.

2 comments:

Rick Hurst said...

Drupal at least has CCK, which allows a non-technical user to create new content types either through the web or by importing a simple schema.

This works really well for non-programmers, as UML and ArgoUML have a learning curve in themselves (I struggle to use and understand ArgoUML, even though I can create an Archetypes schema by hand).

Sure, you can't do as much with CCK as you can with UML in terms of "real" programming, but it works really well for creating custom content types.

Many web developers (myself included), who lean more toward the front end would rather leave the programming to the programmers and use their building blocks to create web sites and applications, which is why it can be frustrating to be dragged too far down the stack and be expected to understand some of the lower-level skills and terminology

Michael Bernstein said...

"With frameworks like Zope and Plone out there, I'd much rather have a good object-oriented person working for me."

Is this a theoretical statement? I'm looking for more Zope work right now.