… would likely program my current project more efficiently. This is one of those textbook examples of how not to build software, but in then end, good enough will (hopefully) be good enough.
I am working an updates to an online application system we developed last year for one of our professional growth programs (where faculty can apply for summer project funding). It worked last year as Colen, my then student programming assistant, coded about 5 days ahead of the people using the system (we have now sample applications from 2004 as models).
There were some problems, especially in the convoluted process for group projects that called for updates this year to be more than switching some parameters in the configuration, and in the end I more or less tore it apart and rebuilt the system. The trick is preserving content for people looking at drafts and applications they did last year, so just about every interaction has to fork for different program content files depending on the year passed to it.
The problem is that I do not typically get nice clean and tidy client outlines, flow charts, and all the stuff they teach you in design school. It’s more or like as I am building the system, there is an email like “can we change the timelines to be embedded instead of linked? Can we change the funding limit? The flow needs to be chnaged- they should not see the budget sheet until they have started a timeline… Can the deans be cc:ed only on approved applications?”
Actually it is pretty close to releasing, and in the end we have simplified many parts of the system, improved the interface, and added a pile of error checking features we did not have last year. But getting the application system up is about 60% of the task, while the applications are open, we next have to build the approval and review processes that are also online.
At times I think 1000 monkeys could likely do better PHP programming than I am rolling out 😉
