TITLE: Reaching a Project Milestone AUTHOR: Eugene Wallingford DATE: August 03, 2004 10:40 AM DESC: an academic shepherds a project to market ----- BODY: Last week, I had a celebratory dinner with a group of folks who've been involved in developing a program that is now ready for prime time. It was a nice to recall the trajectory of a project that has been useful to me in several ways. The dinner was called by the leader of the project, Ed, a mathematics professor who specializes in early elementary education. Several years ago, he and I hooked up over his desire to have a computer program for assessing the performance of students who have been taught to basic arithmetic facts in a particular way. His research has identified a set of strategies for doing simple addition, subtraction, multiplication, and division, and a set of strategies for teaching students. What he needed was a way to tell whether and how well students were using the basic facts strategies. He needed the answer to these questions in order to demonstrate that his approach was working. More practically for teachers, answers to these questions could serve as diagnostic information, helping them know which students need more work with which strategies. Such data can make the dream of individualized instruction more of a reality. I did some initial design work with the math professor and then turned the bulk of the code writing over to Masa Noborikawa, an M.S. student in search of a master's project. Masa's interest lay in the role of design patterns as targets for refactoring during the evolution of a large project, and this project gave him something large enough to grow over many months, refactoring and introducing many of the design patterns he'd learned about "in the small" in his courses. The result for the larger project was a first version of an assessment tool, written in Java. Our first version had a couple of weaknesses that we needed to address. The first involved portability. Now, Java is characterized as "write once, run anywhere". But when anywhere includes old Macs running various versions of older Mac OS, Java -- especially its graphics library -- doesn't run as cleanly everywhere as we had hoped. The second involved networkability. As written the program was a single-user, single-machine tool. But teachers needed to be able to amalgamate data across machines and classrooms, and school districts wanted to be able to the same across different schools. The program needed to be networked with a central server and database. We went through an uncomfortable hiatus in the project. One of the risks for long-term projects at a school with only a small master's program is the the unreliable flow of manpower and skills. When I was a graduate student, we seemed to have an endless supply of new students looking for projects and ready to work. As a researcher at UNI, I often hit dry spots when suitable students are sparse. It's one of the downsides of a program like ours. Eventually I found the perfect person for the job, Ryan Dixon, an undergraduate with a lot of experience programming on Macs. Not only did Ryan have the right experience for the job, he is a good software designer, user interface designer, and programmer. He took control of the software and produced a Version 2 that addressed the above weaknesses and more. In particular, he created a parallel UI that depended on Java 1.1.8 or less, so that the program would run the same on all platforms, even the abandoned Mac OS. Since then, Ryan has gone off to graduate school, returning to do some work for us this summer. We also have a local consultant who has added some of the networking capability and other extensions. Anyway, as the project reaches the point of being marketed as a part of a mathematics curriculum for use in schools, the lead math professor brought us all together, with our families, to celebrate the achievements of the last few years. We all enjoyed a nice meal and the good company. Of course, there is always more to be done... This is my first experience as an academic working with internal client who is taking a project "commercial". You get to learn more from working on real projects than you can ever learn just by reading and hearing about others' experiences. I have along track record working on real projects with real clients, but this is the first on which the resulting program will be used by a mass audience outside of the client's office. In this case, our client isn't even the user -- just someone who has lots of ideas about the project and who works with the real users. Much of my job on this project is listening to the client figure out what he wants, listening to him talk out loud and asking questions, sometimes rhetorical. When Ed says, "Do you have two minutes?", I know two things: As with most clients, he often doesn't really know what he wants. As with most non-software people, he often doesn't even know what is possible in a program. As a result, he asks for too much or for not enough, sometimes at the same time. By participating in the conversation, I help him find the boundaries of the technology while he thinks through the boundaries of his project. Magically, sometimes it all comes together. Version 3 of the program could be awesome, but how we'll get there is yet unknown. It's hard to get rich writing programs for educational markets, but there is a chance that this could take off. This curriculum shows promise, and the assessment program opens doors to possibilities that are unavailable to most elementary curricula. But even if we never make more than a token royalty check, the project will have been worth the time and energy. -----