Distance Learning - Great leveler but has its growing pains…

I was certainly excited back in 1998 when my company offered to provide full tuition reimbursement for a new and exciting “distance learning” program.   Not only were they willing to pay for the tuition if I my grades were “B” or above, but they were willing to support my supervisor at work proctoring the tests that measured my success.

With young kids at home and a habit of working 50+ hours a week with a long commute on top of it, this was an opportunity I could not pass up.  The course selection was great and quickly confirmed Kennedy Western’s claim that they had top professors, and selected text books based on what top Universities used for equivalent courses.  I can confirm that, unlike many of my colleagues, I still use the text books that the courses were based on.   Below are two examples for Artificial Intelligence and Formal Language and Automata classes respectively.   At the time I was working in a Natural Language Understanding (NLU) group developing a product that integrated Automatic Speech Recognition (ASR) and voice playback including Text to Speech (TTS).   I still consult these books today.  But I want to focus on a third book on user interface design – About Face (Alan Cooper).   Even before I completed the class, I ordered copies for my team to get everyone applying these simple and elegant principles to our product.   So more than validating the claims that the textbooks were the same as used at “regular” schools, they were and continue to be directly applicable to my work.   This is an investment which has had both short term and long term pay back for my company.    One final perspective on this point -  my thesis involved programmatically creating candidate answers from a question.  This research contributed directly to features that were added to the application development toolkit I was constructing at work. 

 

The down side?   Well since then, there has been a lot of criticism and marginalization of distance learning, including many claims that they are “degree mills” – you are just buying the degree.   I have no doubt this happens and for reasons I do not understand, Kennedy Western has been included in some of these criticisms.   What is going on?

I can only tell my experience.  Quite simply, I received the book and for the most part, instructions to learn virtually all of it.  At a time of my choosing, not to exceed a fairly significant time (I think it was a year), I could request materials be sent to my Proctor (a supervisor at work) who administered the tests and mailed the results back with no one else touching the results (that is, I handed him my completed exam after four grueling hours and that is the last I saw of it until I got the scored results back from the school).   If you didn’t pass the test on this try, you had one more try and that was it.    For me, this was a much bigger challenge than “regular school” on three fronts – 1). it took some real discipline to work so completely independently, 2) given no preview of the test and the comprehensive coverage, it was most students’ worst nightmare – a comprehensive final, and 3) the all or nothing nature means there was no room to make up for poor test taking by doing a research paper, book report, or getting extra credit by helping correct undergraduate papers!  I have undergraduate degrees in Computer Science and Psychology, and attended several classes at “regular” graduate school before the need to feed my family exceeded my academic pursuits.   I have to say this style of distance learning administered the purest, most unbiased testing I have ever experienced – either demonstrate mastery by performing on the test or no credit was given.   Well Ok, I have to admit I was quite challenged by what has turned out to be one of my most valued classes – Formal Languages and Automata.   In this case,  I asked for support with some trepidation and was delighted to receive phone and email support from a professor at Rutgers University.   More claims validated – top materials with quality support.   What a bargain for me – tuition at a fraction of a “regular” college but with top notch materials and staff.   Of course, I did 99% of the work at little cost to the school – no classes, no “quizzes” or hand holding except when I was really stumped.

So, I think it’s clear I would compare my experience earning a Masters Degree in Computer Engineering from Kennedy Western with any other program.  The fact that I could integrate classes and my thesis directly into my activities at work not only enriched both but justified my company’s investment in me and the program.  There are certainly many who are motivated to see the distance learning movement fair and curb or diminish the value of publicly available training, but I hope for exactly the opposite.   Distance learning, collaboration, and testing; coupled with on-line resources like Khan Academy and vast “open source” style resources, offer anyone the opportunity to not just learn, but to contribute.   Distance learning can be the great leveler of the have and have-not playing field, changing the basic value proposition of “an education.” 

OK. I was an early adopter and early adopters always have their challenges and detractors, but I still am a deep believer that the education served up over the internet can result in consumers that are limited only by their own abilities and willingness to work hard.  This educational model will enable everyone to participate in the 21^st century version of the American dream. 

Example Texts (note links are to newer editions)

Class: Formal Language                     Book:  An Introduction to Formal Languages and Automata
Class: Artificial Intelligence               Book:   Artificial Intelligence, A Modern Approach

 

Cost Justification Required

When I book arrangements through my company’s travel software, it has a bunch of rules embedded to help me make the best spending decisions that I can. If I book a hotel that is out of policy - for example it’s not a preferred provider, I must justify this decision by entering something like “hotel is where the event is taking place” – and that’s usually it. I am sure everyone is familiar with this kind of cost justification whether automated or in the form of some additional information submitted with a purchase order. In these days of ever-tighter monitoring of costs this is becoming a way of life.

I had an amusing thought about cost justifications - as open source content and software continues to be pulled into the fabric of enterprises at all layers, I wonder if will we reach the day when a department must provide a “cost justification” because they are using commercial software when an open source alternative exists? Will we see a day when such a rule is coded into the automated approval process for purchase orders? Imagine it.

....................................................................................................
FUTURECORP: Cost Justification (from the office of the CFO)

Software Purchase Request – Justification Required
>>> You are requesting software priced at $500,000.00 when an open source alternative exists with no licensing costs. <<<

Please provide justification for this choice.

Request: Application Server

Purpose: Host dynamic web applications

Standard Features:
- J2EE compliant Application Server (Servlet, JSP, EJB3, JMS, JMX, web-services)
- High availability (clustering)
- Administration Console

Additional Features:
- Portal software
- Database Support

If your request requires commercial licenses, please list the additional features that make this expenditure necessary:

....................................................................................................

Oh I know the world is not that simple, but there are certainly indications that organizations are building evaluation of open source software into their acquisition processes. Consider this memo from the Navy dated July, 2007:

“This memorandum provides guidance for all Navy and Marine Corps commands regarding the use of Open Source Software (OSS). The objective of the Department of Defense (DoD) goal of achieving an interoperable net-centric environment is to improve the war fighter's effectiveness through seamless access to critical information. A key piece in supporting the DoD goal is the ability to utilize OSS as part of the Department of the Navy’s (DON) Information Technology (IT) portfolio.”

As confidence in open source increases and there is assessment criteria based on core features, it’s not really too hard to imagine the spirit of this “cost justification” becoming reality.

Does your Collaboration Environment “Break the Flow?"

I spent quite a few years of my career designing user interfaces. One of the software tools I developed was a service creation environment (SCE) used to build and deploy applications that presented speech and telephony interfaces. I was lucky enough to be able to study user interfaces from the perspective of the tools that modeled the application (the GUI the developer used) as well as the voice interfaces the design tool modeled (VUI of the application produced by the SCE).

There are some fundamental UI principles that one can glean from literature, research, and of course from actually creating good interfaces, especially when you are working with creative people. There are some really neat techniques specific to the environment you are trying to make effective, usually with the objective of making things so intuitive that, as a user, you don’t even notice them. Like quality service from a good waiter, you get what you need but are not constantly aware of his presence.

In many ways, all these best practices and UI techniques roll up into a very high level guiding principle - and that is to not “break the flow” of the user. What does this mean? According to Wikipedia, “Flow is the mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity. Proposed by psychologist Mihaly Csikszentmihalyi, the concept has been widely referenced across a variety of fields.” (http://en.wikipedia.org/wiki/Flow_psychology )

So “breaking the flow” means diluting that immersion, sapping that energized focus, and jeopardizing the “success in the process of the activity” through distractions. Some examples of “breaking the flow” for a computer user include making him stop what he is thinking about or entering into the application to consider where to save a file to disk, needing to search through a list of icons to find the right tool for a task, clicking through many unrelated forms to accomplish a task, or having to read help to find a feature. In short, anything that requires the user to turn his attention away from the task he is trying to accomplish to tend to the needs of the software.

I find myself considering this principle as it applies to a broader set of activities in the collaboration process, especially as this area explodes with opportunity. Working collaboratively can inherently “break the flow.” You need to wait for someone to update their section, review your work, or post comments to a forum which will change you next actions. While everyone recognizes the value collaboration can bring, there is often little attention paid to the additional efforts involved.

But here I want to specifically consider the role that the environment plays to fold these necessary collaboration activities into “the flow.” Does the environment help to minimize the “break in the flow” that is part of collaborating? This is a question I have begun to ask myself as more and more computer-based collaboration tools materialize. Does the supporting software minimize interruptions or make them worse? Are the interruptions constantly diverting attention or are they grouped in a way that minimizes changing the train of thought? Are interruptions necessary to collaboration or missed opportunities for transparency? In short, does the environment “break the flow” or support collaboration through existing work habits.

I find the following activities consistently “break my flow.” Having to find a URL of a portal for one of the many teams I am working with so I can check out and download a document before I can edit it – after I have logged in of course. Having to deal with finding a temporary spot on my disk to make an “interim copy” which I then have to upload and check in later. Discovering that the document I wish to work on remains checked out to a coworker who just left for an undeserved two week vacation to Aruba. Getting emails that tell me someone posted the word “Thanks!” to a forum. Having to cut and paste information such as URLs from one collaboration area to another. Oh yeah, and rummaging through long lists of loosely related documents to find the one I am supposed to comment on.

All of these activities have the characteristic of making me figure out some tangential aspect of the collaboration process, interrupting the flow of the work I am trying to get done. Some of these could and should be solved through better interface design in the collaboration tools. Some can be addressed through better integration of tools (e.g. single sign on, well structured portals, searches, and tools that support how I work today such as integration with email and shared disk drives). Some can only be solved by creating social norms around the collaboration process (use “reply all” sparingly).

This idea of “not breaking the user’s flow” is really very simple but often very hard to achieve. It is frequently overlooked as a design objective, especially amongst the more geekish who understand what is going on behind the scenes. To sponsors of development projects, it can feel like a bit of paradox to invest heavily to make something as simple and transparent as possible. When something is elegantly simple, it’s easy to say “what was so hard about that?” Once you see it, it’s obvious. But this is a hallmark of good design in any discipline. Simplicity can be complex to achieve.

So while it may seem obvious, “don’t break the flow” might be a simple guide to help organizations choose, configure, and integrate collaboration tools. I firmly believe it is the critical element to adoption. Like the waiter who can clear your table without interrupting your conversation with fellow diners, a collaboration environment should enable you to incorporate the additional tasks involved in interacting with others so seamlessly that you are not distracted from actually collaborating!

Loose Coupling – Unraveling that ball of Wires

I was returning from an architectural planning session with a customer who was looking to modernize a very old but very mission-critical application. They had the usual reasons to modernize – hard to leverage newer technologies, hard to find skills to maintain the legacy code, and so on. They also faced a requirement that often times only becomes obvious after some study – both the new and the old applications needed to run in tandem to avoid a “big bang” conversion. This application was so mission-critical, no one could risk that. But the current application is a tightly coupled monolith of processes and data files that has decades of extensions and hand-coded adaptors to make it the mission-critical work-horse that it is. Components would be migrated iteratively, but the tight coupling in the existing system meant the new system had to run in parallel throughout the migration.

As I began to unwind on the plane, I mulled over the complexity of their challenge. You can lay out a general architecture that is based on the lofty SOA principle of loose coupling, but when you get into it, there is a whole lot of unraveling to do before you can really reach that tidy nirvana. My mind wrapped terminal applications, unraveled data files, and created JCA adaptors as the engine noise from my wing seat lulled me to doze back in time…

I was back in my college days, playing in my band. Instead of enjoying the crowd’s appreciation of my solo in “Freebird” I was “reminiscing” about all of the work that went into playing out somewhere. We finished playing a job and the appreciative crowds left behind only the empty beer bottles. We were in the middle of that massive exercise to tear down the equipment. Ah the glamour.

We had to tear down all the equipment where we practiced and set up again to play, and now we were reversing the process to go home. A lot of time went into disconnecting and reconnecting components using the many, many wires. Microphone to PA, PA to stage speakers, PA to monitor speakers, power to PA, amplifiers and lights, tape decks to PA, PA to tape deck for recording…. There are lots of different kinds of cables to connect lots of different kinds of components. Of course a big part of the challenge was to have our equipment work with the resources provided by the place we were playing. I can still picture cords, hoping they would reach where they needed to or that the plugs would match or that the cable still worked after the abuse of moving.

The great nemesis after the jerry-rigging and changes made while we played was the tangled ball of cords at the end of the night – in fact I considered naming my band just that - Tangled Chords – it was the late seventies. Two o’clock in the morning and we can’t go home because the wires are so tangled up, not just with each other, but around the legs of tables, bar stools, microphone stands. No matter how carefully we laid them out when we set up, by the end of the night they were completely entangled. Some form of entropy I suppose.

Turbulence brought me back to my seat on the plane. “The wiring for setting up a band would make an SOA architect blush” I thought. I considered the analogy more deeply because as a band, we put a lot of thought into how to make the moving process “more agile.” The tangle is created by the things in the club you cannot control – if you plug this in here it will only reach to there. The speakers have to be on that shelf. You can’t run wires across where people walk. Or, the power outlet does not accept a ground so you can only plug in over there with an adaptor. Similarly, the entanglements in a would-be SOA architecture are most protracted around the existing concrete things – the way people interact with the system, data that is shared by existing processes, and key processes that are off limits to change.

The lesson? In both situations you can see that, without care, the new system will inherit the tight coupling of the existing system. And the approach to reducing this effect seems quite similar to both worlds:

• Simplify the existing environment (get as many entanglements and obstacles as possible out of the way up front)
• Make the existing resources as easy to use as possible before you start using or integrating them in your new system.
• Create a master plan – a schema of the best layout if you will. Understanding all the connections you need to make helps understand how to keep things separated.
• Use a centralized connection point – in the music world this is a mixer board that allows you to change logical connections without moving wires. In IT this is probably an enterprise service bus.
• Plan for change – there always will be surprises. For the band this involved having a “toolkit” of adaptors, extension cords, extra wires, and so on that helped solve a problem without heading out to the store to buy a widget we did not anticipate needing.
• Coordinate your activities with people responsible for other elements in the system.

A note on how basic the last point is. We played in some old bars where the wall sockets did not allow for a ground. When each band member set up his own equipment we would argue over who got the adaptors and wall sockets which quickly became scarce. The solution was to reshuffle the octopus with each new need to plug something in. With some coordination we realized that setting up a power strip as soon as we got there provided power for all and only required a single ground adaptor if one was needed. This sounds like a pretty obvious solution but its amazing what can happen without some coordinating influence.

Thinking about the migration problem my client was facing in the context of the concrete steps we evolved to facilitate setting up our equipment many years ago brought some clarity in my mind. Considering the steps we evolved, the challenges seemed a bit less daunting. I deplaned feeling confident I could avoid getting tangled up in blue.

I have ideas I haven't even thought of yet!

I have ideas I haven’t even thought of yet. I had a college professor who used this phrase quite negatively. He meant the guy who really had no ideas but considered every thought he had a real jewel. But I love this thought and think it expresses a certain pressure that energetic creative people feel – that in the right situation given the right information they will generate ideas that solve life’s problems. As organizations are turning increasing to collaboration solutions enabled by “web 20” technologies to bring people together, I have great optimism that we will see increased productivity from folks who have ideas they haven’t even thought of yet. Why? Because well-organized collaboration has the potential of fulfilling the predicate in my interpretation - in the right situation given the right information they will generate ideas that solve life’s problems. Collaboration technologies have the potential to create the right situation –the right problem being posed, the right people listening, the right timing, the right community to tackle something. Collaboration technologies have the potential to make the right information available – that’s central to content management systems. The good news is, even if my cynical professor was right, increased collaboration will increase productivity because real collaboration creates a kind of filter for ideas. If these folks really don’t have any ideas they won’t have anything to collaborate about! . But if my optimistic perspective is accurate, better technology applied with the right collaboration principles should enable these frustrated contributors to “maximize their potential” – and we will all benefit from that.