Sometimes a hyphen is just a hyphen

I had to smile as I read a recent post by Alfred Thompson on validating character input strings for name. In it, Alfred walks through a number of ways to test for valid alphabetic characters while not limiting it to only the 26 letters of our English alphabet.  Most options did not return the results he had hoped for.

You see, overly aggressive character validation was one of the reasons my wife became a programmer. Early in our marriage, Mrs. Advisory Bored used a hyphenated maiden/married last name. Most computer systems would not accept "maiden-married" as a last name. At some point she figured she couldn't do any worse than those programmers and she changed careers. 

I seriously doubt these businesses had a policy that said we don't want women with hyphenated last names as customers, but that's what they implemented.  It is important that programming students understand they aren't implementing code, they're implementing the business.  The implementation can't (properly) occur without the business context. 

And that's a lesson that is just as important as the return value from the isLetter function.

Teachers, unions and the Geo Prizm

Mrs. Advisory Bored and I both broke into the IT world as employees of Electronic Data System (EDS), a whole owned subsidiary of General Motors (GM). That honor bought us a one-way trip to the suburbs of Detroit, MI.  While there, we bought ourselves a new car, our first "new" new car.  We weren't really interested in an early 90's GM product, but that was neither the time or the place to buy Japanese.  Fortunately GM had opened a joint venture with Toyota to learn lean manufacturing techniques so we bought a Geo Prizm, Chevy's version of the Toyota Corola.  We owned the car for 17 years and logged plenty of memorable trips in the East and the most important one, moving back home to Seattle.

This joint venture was called New United Motor Manufacturing, Inc (NUMMI) and was located at the site of the old GM assembly plant in Fremont, CA.  What was so interesting about the NUMMI facility was that it was staff by former workers of the Fremont plant, generally considered to be among the worst workers in the industry producing some of GM's worst vehicles.  Re-energized and re-trained in the Toyota Production System (TPS), however, the plant lead by Toyota management started to produce a range of Toyota-designed products starting in 1984 until last year when the plant closed after GM pulled out of the partnership.  The lesson to be learned was that while the UAW did itself no favors, union workers were not the problem. It was a change in leadership, a focus on quality, a top notch design and radically re-envisioned assembly model that made the difference.

It is well worth considering this lesson as we attack "bad" teachers and their union.  When bloodletting is finally done, all you may be left with is a group of demoralized employees futilely trying to assemble a model that is ill-conceived and out-of-date, handed down to them by a bunch of bean counters more concerned with the numbers on the paper than the product on the street. If, as happened at NUMMI, we identify a new, better way of working first, the problems that need to be fixed may well fix themselves.

Just sayin'.

Abundance, the mother of purchase orders

Good friend of the Advisory Bored blog, Paul over at Last Great Road Trip, is at it again. He's been busy playing around with the technology. When Paul isn't giving some one's data center an extreme makeover, he's either roaming the trails in a Toyota FJ or blogging about roaming the trails in a Toyota FJ.

In a recent post, Paul decided to build himself a good old fashion mobile GPS command center out of inexpensive or free parts.  A second-hand laptop, some open source software and an inexpensive GPS receiver makeup his system (I'm guessing the nice vehicle mount for the laptop described in a subsequent post cost more than the rest of the system put together).

All of which reminds me that resource constraints aren't always a bad thing. Sometimes we forget that a little tinkering, some kludging, a roll of duct tape and a bit of ingenuity can lead to some pretty interesting outcomes and some really powerful learning (which is, after all, the only outcome of any real importance). More money doesn't necessarily improve learning.

Certainly you can plop 30 students down in a lab, each with a copy of "Google Maps for Dummies", but does that really make for more compelling resume entry than the experience of "building a mobile GPS command center, including configuration of the hardware, operating system, mapping software and integration with freely available online map information for under $75.00"? Do you really think the former learned more than the latter?

Remember, necessity is the mother of invention. Abundance is the mother of purchase orders.

If it ain't broke, re-envision it

I've been reconsidering my If I had a hammer post this week because of some discussions I've been having about the redesign of our "broken" web site.  I've tried to steer folks away from terms like "broken" and "fix" when dealing with changing requirements, but the average person isn't so concerned about the semantical differences. I found myself having to be much clearer in my reasoning than I was in the blog post.

Now I don't really care to engage in pointless arguments over semantics if I don't have to, but our words do matter a great deal.  The language we use drives our thinking and, consequently, drives our behavior.  When you say something is broken, you are inherently saying that the system in question - whether a simple appliance or a large social institution - is fundamentally sound and still capable of producing the outcome you desire, if you can fix the one malfunctioning part.

Saying that a system is broken puts you into troubleshooting mode. Think about troubleshooting for a moment. If a user says "my computer won't work", what's the first thing that comes to mind?  Does it involve the electrical outlet or perhaps you want clarification on the current status.  Either way, in troubleshooting mode you immediately move to the beginning of the process and work forward asking a series of yes/no questions looking for components that aren't functioning or are not functioning to standard.  That's how we are trained.

What if, instead, that user said "I have all these new job tasks and I can't find the tools to help me get them done. This computer won't work for me."? Your attention is immediately focused toward the end of the process and the outcomes. Your questions are open-ended and probing for understanding. You are in requirements mode. Imagine the look you would get if your first response to this second question was "Is the computer plugged in?".

In a recent post, "Who's Asking", Will Richardson advises leaders in educational reform that they must some how satisfy the complaints of the school-is-broken crowd without losing sight of real need, which is a re-envisioned education system focused on 21st century outcomes.  In my mind, however, there is only so much that reformers can do until the question is rephrased from "what's wrong" to "what should we do". This is pretty much the same thing I said in this rant 2 years ago in response to a Scott McLeod post about building community backing for 21st century skills.

I think IT leadership is (still) uniquely positioned to help educational reformers, but not until we are clear in our own minds that we must first redefine the goals of education before we change the structure and funding of education. Let me recommend this post on Redesigning Education in Fast Company Design as a starting point.

Tag, you're it

This week I was investigating QR Codes and Microsoft Tags when I came across this article from EDUCAUSE . As a quick background, QR Codes and Tags are types of matrix or 2 dimensional barcodes that contain information that a reader on a smartphone (using the built in camera) can use to route users to a website, add contact information to an address book or make a phone call.

For instance, the image you see here is a Microsoft Tag with the web address of the Advisory Bored blog embedded. If you had a smartphone with the free tag reader you could point your smartphone camera at the image and it would launch the browser and navigate to the Advisory Bored blog. Now imagine if the image were on a business card, placed in a newspaper ad or printed on the side of a bus. (I was researching the idea of printing a Tag on those big white land use signs that go up whenever there is a new building development or a zoning code change.)

It was not, however, the use of QR Codes in particular that most interested me in the EDUCAUSE article; it was the cross-discipline student project highlighted on the first page.  The project has at least four major aspects.  First, there is the biology, compiling the information about the plants.  Second, the team members had to deal with technological issues like information access and user education/training. Third, there was the information management challenge to make sure the content presentation was sensitive to different technologies (phones vs PCs).  Finally, there was a myriad of logistical issues from coordinating with the docents to printing the QR Codes to staffing the guest booth.

More and more, work is characterized by this type of team project in which different people from different areas of the organization (and across organizations) must collaborate to accomplish a goal.  It is my sense, however, that educational assessment, particularly in secondary schools, is still focused on individual performance.  On more than one occasion I have heard from teachers that group projects present significant challenges for student assessment.  That's unfortunate, because those are precisely the skills the workforce of today and tomorrow need.  

An example that's a little closer to home is the Western Washington University V45 project team for the Progressive X Prize competition, a $10 million dollar challenge to build production-capable cars getting 100 MPGe.  Look down that participant list.  You've got business students, materials sciences students and vehicle design students all working toward that prize.  (The V45 was eventually eliminated, but did an outstanding job getting to the finals.)

So what's the take-away?  I'll toss out four, just to get us started:

1. project management and collaboration skills are essential and should be fostered even at the high school level
2. projects that cross areas of study and extend out beyond the campus are far more interesting and potentially more educational
3. teachers will need to develop curriculum that is team-based and be prepared to address all the issues that teams present (such as the ability for teams to "fire" members who aren't participating)
4. advisory boards need to be clear and indicate if they think a program should emphasize "team project work" or "individual project work"