September 2010 Archives

When others find that my wife and I have decided to homeschool our children inevitably they ask, "Why?" I've always tried to answer this question with tactful precision and achieved a varying degrees of success. Today I discovered a description that defines how I feel about what's wrong with public schooling in a wonderfully clear and precise way. It's found in The Cambridge Handbook of the Learning Sciences and authored by R. Keith Sawyer:

By the twentieth century, all major industrialized countries offered formal schooling to all of their children. When these schools took shape in the ninetieth and twentieth centuries, scientist didn't know very much about how people learn. Even by the 1920s, when schools began to become the large bureaucratic institutions that we know today, there still was not sustained study of how people learn. As a result, the schools we have today were designed around commonsense assumptions that had never been tested scientifically.

Sawyer goes on to outline these problematic "commonsense assumptions" as follows:

• Knowledge is a collection of facts about the world and procedures for how to solve problems. Facts are statements like "The earth is titled on its axis by 23.45 degrees" and procedures are step-by-step instructions like how to do multidigit addition by carrying to the next column.
• The goal of schooling is to get these facts and procedures into the student's head. People are considered to be educated when they possess a large collection of these facts and procedures.
• Teachers know these facts and procedures, and their job is to transmit them to students.
• Simpler facts and procedures should be learned first, followed by progressively more complex facts and procedures. The definitions of "simplicity" and "complexity" and the proper sequencing of material were determined either by teachers, by textbook authors, or by asking expert adults like mathematicians, scientists, or historians - not by studying how children actually learn.
• The way to determine the success of schooling is to test students to see how many of these facts and procedures they have acquired.

This traditional vision of schooling is known as instructionism (Papert, 1993). Instructionism prepared students for the industrialized economy of the early twentieth century. But the world today is much more technologically complex and economically competitive, and instructionism is increasingly failing to educate our students to participate in this new kind of society. Economists and organizational theorists have reached a consensus that today we are living in a knowledge economy, an economy that is built on knowledge work (Bereiter, 2002; Drucker, 1993). In the knowledge economy, memorization of facts and procedures is not enough for success. Educated graduates need a deep conceptual understanding of complex concepts, and the ability to work with them creatively to generate new ideas, new theories, new products, and new knowledge. They need to be able to critically evaluate what they read, to be able to express themselves clearly both verbally and in writing, and to be able to understand scientific and mathematical thinking. They need to learn integrated and usable knowledge, rather than the sets of compartmentalized and decontextualized facts emphasized by instructionism. They need to be able to take responsibility for their own continuing, lifelong learning. These abilities are important to the economy, to the continued success of participatory democracy, and to living a fulfilling, meaningful life. Instructionism is particularly ill-suited to the education of creative professionals who can develop new knowledge and continually further their own understanding; instructionism is an anachronism in the modern innovation economy. (R.K. Sawyer, The Cambridge Handbook of the Learning Sciences, Cambridge University Press, 2006.)

It's not that instructionism isn't good, it's that it's incomplete. It was never designed to be more than an instantiation of, and a response to, these fundamental "commonsense assumptions" about what it means to be educated.

I believe there are probably as many different approaches to education as there are people, but this approach, embodied in instructionism is the problem. As long as any educational pursuit approaches learning from this perspective alone, young people will continue to enter the global workforce unprepared for the demands of the modern economy.

I want my children's minds to be factories for new ideas, not just warehouses of facts and procedures.

This year marks the 40 year anniversary of the Xerox Palo Alto Research Center, usually called Xerox PARC, or now just PARC. Ethernet, Laser printers, the mouse, the Graphical User Interface (GUI) and even the Dynabook all came out of this uncommonly innovative place, and then promptly left the building. In many ways, Xerox PARC is more famous for the innovations that it couldn't hold onto, than the ones it could retain and capitalize on. Today, PARC will celebrate the start of their fifth decade at its Palo Alto headquarters, and I think it's worth looking back to see what can be learned.

What Left

The Dynabook started as a concept created by Alan Kay in 1968, just a few years before PARC was established on July 1, 1970. While the focus of the Dynabook was to give children access to computing, the Dynabook proved to be the forerunner to both the laptop and now the super-successful iPad. In 1973 Xerox released the Xerox Alto which some say was originally called the interim Dynabook.

When the Xerox Alto was released with it came Ethernet, a Graphical User Interface and the novel mouse used for pointing and clicking instead of the then popular command line user interface. This was the beginning of what we think of as modern computers. Surprisingly, it wasn't until 1981 that these amazing inventions were put into a commercial product: the Xerox Star. In fact, the Alto was never intended to be a commercial product! Ethernet has now become the hardware layer of the Internet and a bit-mapped display and graphical interface the standard for modern human-computer interaction. If that wasn't enough, the Alto included the first WYSIWYG document preparation systems, new advanced programing language, Smalltalk, and one of the first network-based multi-person computer games! Of all those iPhone and iPod touch games everyone is playing these days, almost every one of them is largely written in Objective-C which was an attempt to bring Smalltalk like constructs to the C programming language. All these inventions in one place, at one time!

On the bright side, about 1 year before PARC was founded, Gary Starkweather (Mac greybeards will know him as the father of Colorsync 1.0) modified a Xerox copier and invented the first laser printer. Eight years later, in 1977 the Xerox 9700 was released and this technology quickly became a multi-billion dollar business for Xerox. Leading up to this, a legal misstep led to Xerox being forced to license their entire patent portfolio to competitors. Xerox's market share of the U.S. photocopier market was said to drop from almost 100% to around 14% in 4 years. While certainly a problem for Xerox, I count the laser printer on the bright side of things because they were actually able to see the future and produce something commercially viable. For laser printers at least, Xerox was able to take the idea and make it reality.

All this background should convince you that when it comes to taking the future of technology to the masses, the stakes are high and yet still this company found it difficult to capture the brilliance of their ideas and make them into actual products. There are probably many and multifaceted reasons as to why Xerox PARC fumbled, but I'd like to focus on one particular facet, that of transferring knowledge from one human to another.

The Social Side

In 2000, John Seely Brown published a book entitled, The Social Life of Information with his colleague Paul Duguid. Brown was a director of Xerox PARC for 10 years. Now, I've watched and enjoyed the melodramatic Pirates of Silicon Valley. I've worked at Microsoft in the Macintosh Business Unit for 10 years. Currently, I'm an iOS consultant and developer. I've read and experienced part of the Mac folklore. But his explanation for why Xerox lost their crown jewels to Apple and others was both new to me and very applicable to everyone in the tech industry.

If Only Xerox Had Known What It Knew...

Brown begins the argument that in tumultuous times, moving knowledge in a company is critical. In fact, much of the knowledge a firm needs to stay ahead of competitors already exists in the firm! Sadly, this knowledge can not always be found, and when it is, it is often impossible to move it to where it can make a difference. In contrast, other firms find that their problem isn't finding the knowledge already present, but keeping it from moving out the door! Sometimes knowledge is sticky and sometimes knowledge is slippery. To quote Brown, "What knowledge the firm can hold on to, it can't use. And what it might use, it can't hold on to."

A side note: For most of the time that I worked at Microsoft the MacBU was located in building 115 which was next door to a huge part of the Microsoft Research facilities. I often took advantage of this by attending the tech talks and technology demonstrations open to all employees. It was a wonderful experience to just talk to those brilliant engineers and have them show me "their baby" and enjoy their enthusiasm. It wasn't until the years brought with them the realization that so much of what I saw, would never make it into any product from Microsoft. When ever I saw another company, big or small, bring to market something the likes of which I had already seen in MS Research I would ask my self, "Why? Why can they do it and we can't?" I never discovered a satisfactory answer to this question, but continued to watch billions and billions more of Microsoft's money be poured into Research. To this day, I think Microsoft's core competency is throwing money at problems and hoping the planets align and something comes out of it.

Now to the part about Xerox and Apple:

Yet most of the extraordinary knowledge generated at PARC never crossed the boundary between the scientist in Palo Alto and the development engineers in Dallas or the management in Stamford. The engineers found the scientists arrogant and almost unintelligible. Management found them naïve and unrealistic. The scientists, for their part, regarded almost everyone in the corporation outside their own community as "toner heads" -- unable to think of the world beyond photocopiers.

The story and the knowledge, as everyone knows, did not end here. For the essence of what had been invented by Xerox in Palo Alto ended up being put into production by Apple down the road in Cupertino. In 1979, Xerox managers invited Steve Jobs, one of Apple's founders, to PARC. Once inside, Jobs was able to see what Xerox management could not, the potential of what PARC had generated. So Apple licensed what it could and replicated what it could not. The knowledge that stuck within Xerox leaked readily through its front door.

Who to blame?

So was it that the management had no vision or that they couldn't work with the brilliant scientists? Was it that the manufacturing engineers couldn't "speak" the language of the scientists? Was it the arrogance, naïveté and unrealistic expectations of the scientists? Of course the answer is: Yes. But the answer could just as easily be, that the folks at Apple understood the folks at Xerox in a deep and fundamental way because they were working on the same problems! For the Xerox scientists, they were dying for someone who understood them, and when they found that the Apple engineers "spoke their language" the knowledge flowed freely. It was a social thing.

The point isn't so much recognizing that people make mistakes and often find others difficult to work with. The point is that developing something new, harnessing knowledge and transforming it into a product is just as much a social challenge as it is a technical one. Getting the right people technically is just part of it, and in many ways Microsoft and now Google are living proof that a high-density collection of brilliant people do not innovation make. The social chemistry between the people is at least as important as their raw intellectual horse power.

But things get really tricky, really quick. Anyone with a modicum of experience knows that Engineering is the study and application of trade offs, but how do you know what to trade and what to off? I've been in meetings where a new and "naïve" developer has proposed massive and sweeping changes to a large code base. The old guard, for good reason, had plenty of ammunition and experience to shoot down the new ideas, but what if? What if the changes turned out to be critical? What if, the short run loss would be far outweighed by the long run gain? The Xerox manufacturing engineers in Dallas I'm sure had many good and intelligent reasons to stand by the successes of the past against the uncertain possibilities of the future. But what if...

It's not just that technical judgement is tricky, it's judging people too. My coworkers who have found me hard to work with might enjoy this story. I was 18 when I first started working at Microsoft. Gary English, a former manager on Apple's QuickTime team had been hired at Microsoft and was looking for another Quality Assurance Engineer, to use Apple's parlance. Grant George over on the Office team had seen my resumé and sent it to Gary. He looked at it, brought me in for an interview and I was hired. A few months later, he, my Dad and I were having lunch and my Dad asked, "Why did you hire my son?" (I never quite know what my Dad is going to say...) I'll never forget Gary's answer, "Well, he had about half of the technical qualifications, but when I found out he was an Eagle Scout and understood the patrol method and came from a large family I knew he would get along with people, and more than half of my problems are people problems, so I knew I'd come out ahead." Now, I'm not about to defend Gary's logic in every case, but the point is that he was making a decision based largely on the social dynamics of the candidate, not on just the technical capability alone. What can I say? I'm glad he did. :-)

Since then as I have been in a position to hire people on my team and observe team chemistry in other teams. All I can say is that the social environment has been for me the number one factor in my personal job satisfaction as well as the explosive X-factor in both success and failure on the teams I have had the opportunity to closely observe. I'd go one step further and say that for an engineer, one hires very often for technical ability not just because the job requires it, but because there's an internal desire to have one who can "speak the language" and really relate to. This socially driven sub-text cannot be ignored in the hiring process. You've got to belong too.

There's yet another problem, and that is that so much of organizational theory set to attack just these sort of knowledge transfer and team problems have as their unstated premise that the people in the firms are homogeneous in nature. Talk of "cross functional teams" ignore the reality of the deep social impact these kinds of teams cause, and therefore, more often than not, the "cross" becomes dysfunctional. I have worked with and stood in awe of brilliant engineers and I can tell you from first hand experience, there is a huge range in the quality of engineers. But it's not just the range, but that the best are so much better than the rest. However, if you have found a few rock stars, a sure way to lose them is to put them on a team where the chemistry is wrong. When rock star engineers leave, their knowledge goes with them. Managing team dynamics is way more important than assigning and organizing the work.

Specialization and Silos

Brown makes the point that, as Adam Smith emphasized, division of labor leads to specialized teams developing specialized improvements to their processes and jobs. But as these teams focus, that very focus often causes them to "develop away from other groups" creating problems of coordination. Management then steps in to "solve" the coordination problems with "process" which in turn often has the unintended side-effect of quelling the creativity! If at this point, you haven't witnessed this kind of behavior in an organization first-hand, well, I'm happy for you, and you haven't been at your current job long enough. ;-)

Tightening controls for coordination almost always leads to reduced creativity, except maybe at Apple. ;-) Certainly their "skunk works" project to develop the Macintosh was an example of loosening control to encourage creativity, but I speak of the current Apple. Apple's organizational secrets are just that, secrets, but one thing I have continued to hear over the years is how organizationally siloed they are. Each team has very little knowledge of the other teams and only a select few interface between the teams and can see the "big picture." While this design might be simply a result of Apple's penchant for secrecy, it might also be one of the key factors in Apple's ability to bring to market new ideas successfully.

The downsides of this super-siloed organizational design is of course that all coordination must be managed by a few and those few will take an extraordinary amount of heat as a result of the friction between groups. On the other hand, over time this very friction could develop into a set of defined boundaries and expectations that leave the several groups fully able to innovate and be creative without the overhead of internal group process. Their process then is their people who skillfully manage the teams both technically and socially. Of course only a few know a great deal about what makes Apple a place where knowledge and creativity can stay and flourish. But who knows, maybe Apple learned one more thing from Xerox way back then, and that one more thing wasn't technical at all, it was the social nature of ideas and development.

Environment

A major reason Xerox lost what they did to Apple was that the Xerox PARC scientists found in the Apple engineers people who looked at the world in a similar way. This similarity in practice and desire to conquer similar problems created an instant social bond and identity between the two groups. It was this social acceptance and mutual understanding centered around a common practice that made it work. But, keep in mind, all it did was make the knowledge transfer happen, there was still a long way to go to turn invention to product innovation. Apple saw the future in 1979, but it wasn't until 1984 that they could actually begin to make the ideas reality. Speaking of this delay Brown says:

This is not a criticism of Apple. Rather, it is an acknowledgment of the organization required to take even something as appealing as the GUI to the marketplace. Within Apple there were many bridges between communities and practices to build. The Macintosh was for a while something of a pariah. The larger Lisa and the older Apple II drew most resources. There are accounts of pitched battles between the old and the new, where the lines of confrontation resemble those between the photocopier stalwarts and PC visionaries within Xerox.

In these conditions, the journey from new invention to robust innovation required hard work, tough decisions, contentious resource allocation, power struggles, hard-won organizational commitment, leadership, and a great deal of trust. It took an organizational leap of faith to build the multidirectional, cross-communal links from R&D, through engineering, manufacturing, sales and marketing, to the market itself. Nothing was preordained. Indeed, the organizational effort was significant enough that developing the knowledge redeveloped the corporation. In all, moving from initial idea to market involved much more than taking it from PARC to Cupertino.

It's easy to sit back and observe large corporations succeeding and failing and take time to opine as to why and what they should have done. The social angle that Brown takes on this interchange between Xerox and Apple brings so much more richness and color to the challenges of any corporation trying to take an invention to market. Certainly, as Brown says, nothing is preordained. When we see successes and failures in the tech industry, the lesson of Xerox is that there is more than meets the eye. This world turns on very small hinges. So many small, but significant things have to go right, so frequently, that it's a wonder to me that anything makes it at all. I suppose maybe that's why you have to love this stuff so much to keep at it. The challenge is so difficult, that only those who love it, stick at it long enough to begin to sense the subtle signs of success.

Only hours ago the 1.0 release of Names hit the App Store. Names is an iPhone app that helps teachers quickly learn student names. I wrote this app because I'm great at remembering faces, but terrible at remembering names.

For the last 7 semesters I taught a non-accredited iPhone dev class at BYU Idaho. We never had more than 25 students, which made it even worse when I would forget a name. I remember one semester a student walked in, named Brandon, but for some reason, to my brain he was named Joe. I would constantly call him Joe, and he eventually stopped coming. I felt terrible. I knew I needed to find a better way. That was the genesis of Names.

How It Works

On the first day of class, as the students leave the classroom, you stand by the door and using your iPhone or iPod touch snap a picture of each smiling face. Add the pictures to Names and practice until you've got them all down. It's that simple.

Here are my favorite parts of this app:

Clean Design

I know this is biased, but I really like the look and feel of the app. I'm not doing anything visually stunning, but with basic controls and simple views I think I've distilled this application down to its essence. This is hard work! Maybe some day I'll show all the iterations and ideas that lead to this, but even though the visual flair could be improved, this app doesn't get in the way and I'm very happy with that.

Casual Review

The review screen comes from talking to and watching teachers trying to learn student names. Frequently they would simply arrange student photos with names on the table. Others would use computer printouts and quickly scan the photos with names right before class. This screen allows for quick review and editing of photos. You'd be surprised how different students look from the student record photo taken years before. The subtle edges of each photo before and after hint when there's more to see.

Practice

When you enter the practice portion of the app, you have a stack of faces and need to select the correct name from three nameplates. While this might seem obvious, it's really a rare solution. First, it's fast. Tapping is all that is needed and you can move through a huge class super quick. Flip transitions that simulate actual pictures or flashcards are slow and lose the connection between the two sides of the card. Second, it mimics real life. In the classroom, a teacher is looking at a face, and then trying to recall a name. That's the scenario and this arrangement helps you perform in the scenario in which you will need the recall. And third, the smooth animations reinforce correct and incorrect guesses without taking too much time. The animations draw the eye to the connection between the name and the face and reinforce the learning.

Focus

One could say that this is simply a flashcard app and in a way, that's right. On the other hand, I'd recommend that any college professor try to use any other flashcard app out there, on the iPhone, iPad, Mac or Windows and see how the experience compares. You see, it's the focus that makes this app great. Sure, you could use Names to memorize anything that has a picture and a name, and I don't go out of my way to make that hard. However, this app is about learning people's names fast. Making a general purpose flashcard app makes it hard to nail that core scenario because you have to add other clutter to support the general use. With a focus on the core scenario, the UI that doesn't matter just disappears. Simple focused solutions. That's what I love about building iPhone applications and Names is no exception.

I'll write more about Names later, but for now check it out for yourself!