What is 21st Century Education?

The term is floating around a lot and I am trying to understand what it means. I am mostly thinking in terms of how a SIS can meet the needs of such an education system, but going a bit beyond that as well. Here's my idea of what a 21st Century Education system MIGHT be like, as a comparison to a very traditional school:

Can one program 'do it all'?

As our ministry of education moves towards replacing our provincial Student Information System, BCeSIS, they have put out an RFP for an expert to give them advice. They want a new SIS that will not only meet today's needs, but also the needs 21st century education. While this is not defined, they do include this description: "personalized student learning plans, irregular periods of registration and completion, and intensive collaboration and communication among teachers, students and parents".

All the SIS I have used (as are the schools that use them) are built around the basic structure of a school year. For secondary schools they are further built around semesters, terms and timetables of classes meeting at specific times in specific places. Individual students come later, being force-fit into those structures. I can also imagine a different type of SIS, centered around individual students, with learning plans, irregularly scheduled activities and the services of various staff associated with that student. What I have difficulty imagining is a single SIS that does BOTH. And I have even more difficulty imagining a system that does BOTH WELL. I hope this is just a matter of my lack of imagination.

My concern is that as we attempt to meet the needs of schools at both ends of the spectrum we may arrive at a system that does nothing very well. Can a computer program meet all needs well?

This is related to my previous two posts. If we decide to design our own 'made in B.C.' solution there is the danger that it will be driven by the myriad needs of the end users, generating a long list of 'features' the system must accomodate. Such lists of requirements are likely to lead to the assumption that any program meeting all the requirements is a good program. That 'assumption of goodness' is incorrect, as a program may meet the requirements and yet be counter-intuitive, difficult to use and frustrating for all.

Maybe one program can meet all needs, but we shouldn't assume so. And we should ensure that whatever it does, it does it well.

The tragedy of end-user advice

Should software designers and end-users listen to end-users? The obvious answer is yes. The correct answer is yes, but...

I have lately been implementing a software module that was designed by a ‘business analyst‘ working closely with a committee of end-users (in this case special education teachers). I believe the design was in effect turned over to the committee, and it shows. I frequently discover behaviours that no sane person could have created intentionally, yet it was created ‘according to specification’.

Software designers need to listen to end-users and work with them intensely to develop a shared vision. That vision should then guide the development. If developers don’t translate the needs of the users but instead let them control the process, the result is software only a mother could love.

Assumed Goodness

Yesterday was 25 years since the Challenger disaster. A NASA engineer from that time attributed the accident to carelessness and ‘assumed goodness’. When the Shuttle program seemed to be going well the engineers let down their guard and began to assume that everything would work properly unless there was evidence to the contrary. Of course with an endeavour as dangerous as space flight it is necessary to assume that nothing will work properly unless there is evidence to the contrary. The loss of the Columbia seventeen years later showed that the attitude of assumed goodness recurs unless intentionally and constantly avoided.

While most software design is not fraught with the danger of space flight, the tendency toward assumed goodness is the same. Software fails because the designer (or the end user – but I’ll get to that later) creates an incomplete specification that assumes implementation in a logical, intuitive manner. If the programmer does not share the vision of the designer the result may be neither logical not intuitive, resulting in a program that is inefficient and frustrating to use.

The only solution I can think of is a lot of work trying to help the entire design/programming team to share the vision. Note that a shared vision is quite different from groupthink, which is a superficial appearance of agreement. I fear that a truly shared vision may only appear in the product it creates.

BCeSIS Deja Vu

I've spent much of the past six years implementing a student information system (SIS) in my school district. It is called BCeSIS, and it is an 'enterprise' system designed for all the 600,000+ students in BC. I've only been implementing for the 4000- students in Quesnel.

BCeSIS is a modification of a SIS called eSIS, written by AAL Solutions in Ontario and used for about 4 million students worldwide. In November AAL was bought by Pearson, which has a SIS called Powerschool used for about 11 million students worldwide. It wasn't hard to read the writing on the wall.

My immediate thought was, 'here we go again' - sort of like jumping in a time machine and going back six years.

My second thought is the one that interested me, and is what indicates to me how lucky I am. While I could have thought 'oh no, six years of my life wasted', I didn't. Instead I thought 'this may be interesting, maybe enough to delay my retirement'.

When work brings that sort of reaction I must be very blessed. And who knows, maybe we'll get it right the second time around.

Why I don't like blogs

I like conversation. Interactive between people existing here and now. Thoughts that exist here and now. Blogs are too much of a history for me. What is in the blog is what I thought when I wrote it, not what I think now.

Blogs in themselves are far from interactive; more like shouting in the dark. But maybe the writing itself is cathartic.

I actually prefer email, but lots of people use email differently than I do, so it may become uncomfortable, more like grabbing lapels and shouting in their ear.

So here I am trying a blog again. We'll see how it goes.