[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
We need to simplfy
I'm not sure how many people here have actually worked on a distributed
free software project like this before, but the quickest way to kill them
is to overdesign the project.
Someone said earlier that it's better to spend some time now designing
rather than having to rewrite everything later. While true, it
doesn't apply as much to projects like this. With something working we
will attract more developers and more users, so the inevitable rewrite
will be easier.
We have two problems right now.
1. We aren't going to get quick, widespread adoption of a district-wide
solution to every educational administrative problem.
2. We don't have enough developers to write that in a reasonable time
frame.
We are better off now deciding which key pieces of functionality are most
important, and write them so they can work independently of other
computers, with minimal infrastructure (like not requiring a relational
database). This is so one teacher can install their gradebook, test
generator, or whatever, and not worry whether their district or school is
running the backend database stuff.
However, they should be written knowing that someday we will want
everything to interact. Exactly how they interact comes later. It would
also be a good idea to make sure they are at least compatible with
existing standards in this area, but from what I know, there are currently
none with wide spread use.
Separating the interface from the core is a good idea. As much as
possible, applications should have a gui, web, and console interface.
And if the interface and core communicated via a socket, it's a small step
to allowing a computer lab full of students to take a quiz or test from
one "server" which is the teacher's computer.
And eventually even the small server piece can be replaced by the
district-wide database of everything.
We can build these tools incrementally, and they will have a much greater
chance of being used, since a single teacher can adopt them without having
to coordinate with the district tech person.
Justin Bradford
justin@scrtec.org