School district builds own software to handle student data, defies doubters

I am not envisioning a simple plugin to a word processing tool; I am imagining a dedicated curriculum development tool that manages things like importing standards, and connecting detailed parts of a learning plan to bigger-picture summaries.

I in no way imagine such a tool being mandated for anyone; I simply imagine a tool that is powerful enough that people will see it used well by experienced teachers, and want to use it themselves.

I don't remember the details, though I was feeling their pain, having to deal with (a) the unbelievably horrid, steaming pile that is PeopleWare, and (b) the clouds of consultants that start calling you up and pumping you for money once it is out that you're doing an install of the pile. (Hint: You don't need any help from a high-price consultant to install PeopleWare. You need a can of gasoline and a match).

So the thought of a school district doing this on their own makes me smile. They could do worse!

As I grow older, I'm increasingly starting to believe that many of the advancements in sophistication of software are actually somehow making it much less possible to successfully implement relatively complex solutions on budget - I am making this comparison to the relatively short era where platforms like PowerBuilder/Delphi/MSAccess were popular. If you mention on of those products now for literally anything, you'll be met with howls of laughter, but for the life of me I don't understand. Meanwhile, spending $2 million on a project that is laughably short on functionality and seems to take weeks to make the smallest of changes is considered (with grave seriousness and 100% infallible confidence) to be perfectly proper.

I would not expect this to be a long term success. Virtually every district of reasonable size starts with a homegrown and maintained solution and ends up going with one of the big guys for lots of reasons.

1. Security/liability. You have to have pretty damn good systems here and definitely want to point at someone else's assurances and contract that allows for recourse.

2. Rapidly changing business requirements. This is everything from state and federal reporting requirements to the expectations of end users. It's hard enough to maintain these core systems and keep folks around who are good enough to do it. Now deal with changing technology (oh you want a parent portal? Oh, you don't want to use Flash/Java for iPads? Oh you want ...) and you really can't attract and retain the kind of software people you'd want to continually redesign, refactor, rebuild, extend, and expand. Development on these systems never stops, which is why it's often easier to just drop off the old and buy the new hotness. It's also why scale is so helpful with these systems. If your users want this, someone else already requested it or will shortly. A lot of the improvements in these systems happen because of how many users they have and can be made because the cost is spread across all those users.

3. Interoperability with other systems. Most of these systems are not omnibus catchall solutions for the entire business needs of a school district. That's probably for the better-- the folks who try to do that end up doing it very poorly. But you will want your HR and payroll to talk to your student information system that should probably talk to your assessment system that should talk to your curriculum management system that should talk to your special education IEP case load management system, etc. It's hard to do this and even harder when your solution is built to work in one context. Standards here have only barely helped. Middleware is expensive, shitty work. Again, not easy to attract killer talent and it is a constant need. The big boys have everything else built and just focus on middleware and have probably already worked with and written what's required for all of the popular systems you are using in these other areas.

This is just the smallest fraction of reasons it's a huge PITA to write and maintain these systems. That's not to say that it can't be done but it is to say that this is not a small, well-defined problem space with just a few distinct end-user types and functional requirements that can be built once and then monitored and tweaked over time. Not if you want to do the real stuff that makes collecting and maintaining all of this data worthwhile.

http://www.schooltool.org

It has been around a long while now, is in use around the world, and should at least make a good starting point for further customization.