Contexts and Practicalities
Before we fully jump into all of the ways in which you can use and create technology in and for the classroom, we thought we could take this week to talk about the context of technology projects and some of the practicalities of getting them done. Most of the information and readings here slant towards software development as that is the space in which most of you will work.
Context
As with almost any project, technological or not, understanding context is important at the beginning. To talk about this we’ll use a modified version of the Five W’s and one H. Asking and answering these questions inevitably leads one to rethink and refactor the project, and hopefully a stronger result ensues.
Why
Questions: why is it being done? what are the goals of the project? what need or problem will it satisfy?
This is an important question because the answers to it inform all of the rest of the work that will be done. Correctly answering it can also be an antidote to project that are done just because they sound cool (although those have their place). An often cited parable is of the NASA space pen. The basic story says NASA spent millions of dollars developing a pen that could write in space. The Russian simply used pencils. While it turns out the story is false, it illustrates the importance of the initial nee d statement. “I need a pen that can write in space,” is very different from “I need to write in space.”
What
Questions: what is it? what can people do with it (features and functionality)? What pedagogy or process does it support?
This is often the place where people start on a project. And it is of course an important piece. Later on we will look at some techniques used to help plan and visualize the what of the project. Before we do that, let’s first step back and think about the assumptions that often go into the what.
Using software (always?) means that you have to also accept the developer’s philosophy, process or pedagogy. So when you plan software before you start with the features it often pays to start with the pedagogy it will support. Think about commons software like MS Word or Blackboard. Based on the features that are present what kind of process and pedagogy do they support? How would a different conception of teaching pedagogy change the features in Blackboard?
In this post by Jason Santa Maria, a web designer, his vision of the perfect web design tool has less to do with features and more about how it fits into his process. He has a process and he hasn’t found a software to fit that process. Unless you have a specific interest in web design you don’t have to read the entire article but at the beginning and end and in the comments you can see that a focus on process (or pedagogy in educational software) over features seems to make much more sense. This begs the question, so why do so few software companies seem to do it that way?
Who
Questions: who is going to use it? who is going to build it? who is going to pay for it?
The who’s in educational technology are usually from one of these camps: Student/Faculty/Instructional Designer/IT Staff/Administrator.
Each of these whos has differences in: access to capital, access to resources, time in schedule to devote to working on it, length of time they will use it (ie students short term, faculty long term), degree of direct involvement in the use of the product, length of time the who has been and will be in the institution, knowledge of subject, and facility with technology. To help think through these different people software developers often use personas. These are fictional users of the system that offer a lens through which the developers can look at what they are building.
Another consideration with whos is how many whos are in whoville. As projects scale in size almost everything becomes more difficult and expensive. For example the CUNY Academic Commons only supports faculty, staff and graduate students. This number is somewhere around 20,000 + whos. If it supported undergraduate students the number would be over 250,000 and if it also supported contiuing education students the number would be around 500,000 whos.
In addition, the more resource intensive the project is, the sooner scale becomes an issue. For example here’s a rough (unscientific and unresearched) estimate of the number of whos that can be relatively easily supported for some different projects:
- Simple Web Site: 1,000’s
- Dynamic Web Site: 100’s
- Voice, Video Chat, Virtual Classroom, 10’s
Higher numbers are possible (Blackboard at CUNY supports 40,000 + concurrent users regularly) but they require expertise and capital.
Where
Questions: Where will it be deployed (online, desktop, mobile, kiosk)? Where will the users be when they use it?
What kind of screen or device a project exists on can have a large influence on what is possible and the development tools available. The ramifications of these different types of projects are more than is appropriate for right now. Often the decision on where it will be deployed is made up front without much thought. Even less thought is given to the location of the users. How someone uses your project may change based on whether they are in their office, at home, in a classroom or in a park.
Currently web development is undergoing some changes in the approach to the where question. The proliferation of smartphones like the iPhone and Android based phones has brought web browsing to handhelds. The initial response has either been to do nothing or create a separate site for mobile devices. This article by Ethan Marcotte suggests an alternative, a way to design for multiple screens at once. It’s too early to tell how it will exactly play out but it appears that future web development will require developers to think about their application in multiple contexts.
When
Questions: when can we get started? when is it due?
Time is an extremely important constraint. Unfortunately experience shows that most software projects go over time, and over budget. One rule of thumb is that after you think through the project and estimate the time, multiply that by at least three and you will be closer to the actual time. The less experience you have with software development or the kind of process/problem being addressed then the bigger the multiplier.
Time can also influence whether you decide to build a solution on your own, use a prebuilt one or do some customization to a prebuilt. system
Practicalities: Build, Buy, Beg, Borrow
With the context sorted out it comes time to actually get the project done. The classic question is do you build or buy? This article is very short but the comments underneath are enlightening. It refers to this well known article by Nicolas Carr where he makes the argument that most of the time the answer is buy. One of the problems for educators in much of this debate is that it is generally done by administrators where large, expensive software is involved.
A lot of advice given boils down to asking these questions. Is the function or process that the software supports core to your business? Is your model or process unique? If what you’re doing is core to your business or unique then you should probably build your own. If not, then buy it. Unfortunately answering these questions is often easier said than done. Many individuals and institutions have trouble answering the question what is your core, your raison d’être, and what we think is unique may not be so unique. Applied to CUNY one could ask if we are right in building the CUNY First system and buying the Blackboard system.
Here a couple of other B’s have been added to round out the picture. We’ll look quickly at each one.
Build
If you have programming skill or like making things this is often the first idea people have. The basic word of caution is that it is always more expensive and time consuming than it seems at first. But it a can also lead to the most useful and innovative result. See “More of Software Development” below for more details.
Buy
Even if you know you want to build you should always look at the options available in the commercial off-the-shelf (COTS) market . Sometimes great, surprisingly cheap software can be found. As state before, beware of the processes and pedagogies that are required and enforced by the software.
Beg
This is a coy description of using free software provided by a third party. Google products (gmail, YouTube, Google Docs) are a great example of these. Many educators are often turning here first simply because of the wide range of freely available products. Just remember that using these requires you to essentially beg. You don’t own the software, and you don’t know how long it will last. This article about DimDim, a conferencing service that was acquired and close, is a case in point. As my daughter’s dance teacher says to kids when they get stickers at the end of class, “you get what you get and you don’t get upset.”
Borrow
Using free and open source software (OSS, FLOSS) lessens the risks of begging by giving you control over the software code. You also have the ability to modify the code to suit your needs. The CUNY Academic Commons utilizes this approach as it is built on a number of open source software applications. However, to truly use OSS most projects also require some buying (such as servers in the case of the Academic Commons) and building to customize the software (and of course building is never free).
Other common headaches include difficult installation procedures and lack of quality documentation. So in the end borrowing can be a faster way than building to get a unique project done, but it is not as simple as buying.
More on Software Development
When choosing to build or customize your own software it’s good to know a little bit about software project development methodologies and their history. What comes next is very brief and reductionist and I would be happy to have people point out flaws and omissions. Wikipedia has this relatively brief history of software development as well.
In the beginning there was no software project management. And all was well until larger systems with many lines of code started to be built. So people realized that they needed some processes in place. The methodology that became widely used is often referred to as the Waterfall Model. It has variations but generally goes something like this:
- Analysis (figuring out what is being built)
- Design (plan how it will be made, like a blueprint)
- Development (make it)
- Testing (make sure it works)
- Deployment (release it out to the users)
- Maintenance (keep it working)
The reason this is called the Waterfall method is that these steps are done in a linear fashion, completing each one before the next is started. Waterfall is also a good metaphor because as the project goes along it picks up speed and momentum and becomes very difficult to change or redirect. Errors made early on can have far reaching consequences.
This process was better than none but all was not well. A large number, perhaps the majority, of projects were late, over budget or simply abandoned. Why? (scope creep aka feature bloat, changing specifications, missed specifications, difficulty in predicting how long a creative process will take, difficult little things that are needed to make an interaction work, lack of prior experience and examples, youngness of the field). Perhaps the biggest reason for the failure of the projects is in the basic philosophical assumption it makes that you can plan everything up front.
In a seminal article “No Silver Bullet – Essence and Accidents of Software Engineering” Fred Brooks made the argument that software engineering will never see orders of magnitude increase in the time and money it takes to make software. But this idea that software development is inherently complex and messy brought about new development models often generally referred to as lightweight or agile methodologies. The major difference with a lightweight methodology is that it assumes up front that things will change. So instead of planning and designing every detail of the system, developers quickly get an idea of what the project is then go out and build a quick prototype (or even part of a prototype), look at it, plan the next bit, build that in an iterative process until the product is developed.
When this methodology is applied to digitally delivered products (especially browser-based applications) the idea of a finished product is often lost. Instead a working version with limited features is released and then as new features are added or bugs fixed more releases happen.
The field of Instructional Design (ID) has similar processes to the more general software engineering. The Waterfall Method is often called Instructional Systems Design (ISD) or ADDIE. It to has come under fire and this often cited article “The Attack on ISD? It’s Slow and Clumsy” by Jack Gordon and Ron Zemke is a great example.
In the end the sheer weight of the requirements gathering and documentation process in older methods like Waterfall and ADDIE, can simply be too much to bear and get the project done. Experienced developers often keep just a few guiding questions in mind when developing a project. Tom Kuhlmann offers an example of this in how he things about making an eLearing course.
User-Centered Design
For the humanists among us User Centered Design is an other development that has come about in an attempt to better the Waterfall method. This design process focuses on the needs and want of the users and can include sociological/anthropological research as part of the process. The process is favored by people who call themselves designers or interaction designers. It is applied to both hardware and software and the goal is to conform the end product to the user rather than vice versa. The Nielsen Norman Group is one of the pioneers in this field and not a bad place to start looking around (look at the publications and the links near the bottom for their articles and essays, the three principles all have sites).
As some companies have come to focus more heavily on design and user experience (UX) as a competitive advantage. A common example is Apple vs Microsoft where Apple is the design focused company and Microsoft values its software engineers over the designers.
The end (at last)
This is all a lot to think about. A bit overwhelming to new software project managers. The goal for this week is not to master all of the knowledge and techniques, but to know they are out there and to begin a dialogue on how this kind of thinking influence, helps and hinders the projects you will be creating. You must do some planing up front but it is impossible to plan for everything. Your process should reflect that and allow for reconceptualising and change while also maintaining a simple focus. Yes, easier said than done.
