Keeping Track

Fair warning: This post is a geeky riff about data and technology.

I just came back to Oakland from a stint in Southern California where I worked for a few weeks at the Teach For America Los Angeles Institute as the Director of Data and Assessments. It was an interesting experience. I should say right off the bat that I am fascinated by the process of keeping track of things. So this job, keeping track of student data gathered during the 5 week summer school session, was really fun for me. (Not without its frustrations, of course — the tool we used to track data was in the early development stage and had a few kinks and quirks.)

When I got home, my attention turned to the process of getting ready for the coming school year, and I started to think about how I am going to mine the data in our school district’s centralized database and cross-reference that data with the information in special education database to find the names of the students who will be my responsibility in the coming year. OUSD, you see, keeps track of students in separate databases. These applications were made by different developers, using different data schema, and using different database systems, so they don’t speak to each other. The process of finding my students requires a lot of typing, clicking, hunting, and guessing.

I know that our information technology and special education departments are aware of the problem, but it seems to be an issue that just hasn’t captured the imagination of anyone who is in a position to actually solve the problem. Quite reasonably, my access to the databases is limited — no one wants a special education teacher poking around in the database with tools that could potentially make a mess of the data. So what’s a guy to do?

I’m at a fork in the road. Part of me wants to forge ahead, stop worrying about things outside my locus-of-control, and just do the best work I can in the classroom. But part of me wants to dig in and solve the data problem. Not everything we need to know to do good work with students requires a well designed student information system, but having such a system is crucial. And having a bad system reflects on how little value we place on having an accurate picture of the students in our schools.

At Edna Brewer I need to use three separate tools to track student information, none of which interact with the others. Teachers use the district’s central system for taking roll, tracking discipline, and recording grades. Because we also print paper progress reports for each student every week, we use a second system for entering progress data which is then printed every Wednesday. Naturally, the data in the progress report system is not automatically entered into the main grade book. And I manage a couple dozen IEPs using a third system. Much of the information about each student is duplicated in those three databases, so if a family moves or changes phone numbers the data needs to be updated three times. (Guess how often that actually happens.)
There are a couple of other pieces of software I use for my own personal record keeping, since none of the mandated systems does a great job of handling the data I want to track.

Data management is hard. Building elegant solutions is not easy. But that’s what is so alluring. I’m not an expert database designer, and I am surely not the worlds greatest application developer, but I have a few years experience working in the application design space. My passion for problem solving is heating up, and I’m weighing the impact I can have as a teacher in the classroom against the impact I might have if I utilize my design skills to make a streamlined and meaningful interface to school’s student information systems.

I believe a well designed system is a reflection of the institution that deploys it. OUSD has many fronts on which to demonstrate its commitment to improving her student’s education environment. A well designed student information system is not enough, but it’s a piece.

Friday August 10, 2012 — Mark —


::