Complicated Solutions

One of the challenges I face in my role is deciding when not to do something. I can see possibilities for systems to work together. I can repurpose technology tools in different contexts to do useful and unexpected things. But building and maintaining these systems takes a long time, and often falls out of the areas that I should be focusing on. I try really hard to straddle the worlds of technology and learning, and these projects always drag me too far toward the technology side.

I often fell into this trap in my previous job. For example, the Internet filter can notify us when students engage in risky online behavior. If a student searches for “how to kill myself,” it can generate an email so we know about it and can provide appropriate intervention and support. But the system is not very robust. All of the notifications go to a single person, who has to wade through them and decide which ones need action. And because the majority of the notifications are innocuous, this can take a lot of time with very little benefit.

In my last school, I created an email address just for these notifications. Then, I wrote a program to check that email account. When it received a message, it would figure out who the student is, what kind of risky behavior occurred, and log it to a database. I wrote filters to ignore some of the things that get flagged that we’re not worried about. Then, another program would compile a single email each day for every school counselor, summarizing the activity of the students assigned to them, so they could follow up if needed.

Roadshow, by Hubert Blanz.

The system worked. It saved a lot of time for the counselors. They didn’t have to worry about the false positives or students who aren’t assigned to them. And they weren’t innundated with dozens of emails every day. But the solution was technically complicated. There are a lot of things that can go wrong. And I was the only one who understood how it worked.

In my current school, we don’t do things like that. The filter is limited to a single email address for notifications. So we set that address to be a group. All of the principals and counselors are in the group. So every time a notification is generated, they all get it. It creates more work for them. They get a lot of messages that don’t apply to them. But it’s a more reliable system, because there are fewer pieces to break.

When it comes to support for the complicated technology stuff, this school is very lean. We rely almost exclusively on outside providers for network and infrastructure support. We don’t host our own servers. We don’t maintain our own databases. Even things like the wireless network are managed as a service by someone else. This approach allows us to focus on our core business: learning. We don’t have to spend so much time worrying about server upgrades and off-site backups and security vulnerabilities. When something breaks, we have people to call. And those people take care of that stuff so we don’t have to.

The simplicity of this approach is attractive. But it lacks elegance. When a new student enrolls, why can’t we automatically generate a network account and email it to the student’s parents and homeroom teacher? Well, that would require the registration software and the student information system to work together in ways that they don’t. And then, a new student trigger would have to prompt three other systems to generate accounts, and then report back that this has happened, so another application can generate the notification, pulling the contact data from yet another place. Those applications don’t trust one another, so they’re reluctant to allow any kind of automated changes. And I don’t really have control over any of them, so I can’t work in the middle to make all of this happen. The result is that manual intervention is required every time we get a new student, and the account isn’t ready and waiting when the student shows up for school.

Sometimes, it feels like I’m living in a blue pill world after having taken the red pill. I know what’s possible, and I’m frustrated that others don’t see the same things I do.

Of course, I know that there are other factors involved. The filter could support multiple notifications for risky behavior, but it’s added complexity for them that doesn’t contribute to profitability. Those systems that I mentioned that would have to work together to make automatic account generation practical include Microsoft, Google, and Apple. All of them would rather have us live entirely within their ecosystems, so they don’t want to make it easier to sync data with one another. The student information system has specific accountability and security requirements for managing data, and that’s all based on users interacting with it through the web interface. So they can’t have a lot of external applications making database changes without those actions being tied to a specific person.

Despite resisiting for a year, I know I’m going to get pulled into building some of these systems. I can think of a half dozen or so that would be really useful right now, and probably another handful that would be nice to have. I just need to be more careful to keep them as simple as possible, document them so others know how they work, and be more selective about which ones I’m willing to own.