N steps forward, one step back
During my 30th week at Learners Guild in Oakland, California, ending on 1 December, I worked mainly on a web application that manages a document repository. Its ostensible purpose is to let users find and retrieve relevant documents from a collection. The collection might be your own, and you might be the only user. Or it could belong to an organization that has users of various kinds. In addition to this purpose, it has two ulterior purposes: (1) to make me learn or relearn methods for developing complete web applications, and (2) to show others, someday, what I can and can’t do as a web developer.
My inspiration has been a collection of documents in my possession, generated within an organization, with various categories of users having various rights to see and retrieve documents. Some of the documents are open to the public, some only to members of the organization, some only to its current directors, and so on. In my previous work at the PanLex project, I also encountered several archives of language documents whose donors had attached various access restrictions to them.
In designing the application, I decided to focus initially on three functionalities: (1) managing the application’s users, (2) regulating user access to documents, and (3) facilitating user discovery of relevant documents. In addition to making decisions about these functionalities, I also decided how generic to make the application.
Initially I semi-consciously chose to give the application a generic tentative name (“DocSearch”), but in reality to embed into it dozens of assumptions specific to a single use case. While working on it I gradually became more conscious of, and committed to, genericity. As I did, I undid and redid many things to separate the specifics from the application logic. The specific messages to users came out of the code; I put them into a file of their own, where they could be replicated in another language for a user community using that language. Then I isolated into one file the customization decisions that an administrator of a DocSearch site would make and protected that file from being overwritten in an upgrade of the software. Initially, I hard-coded into the application a set of user categories. Later I recognized that as anti-generic, so I redesigned the system of user categories to allow an administrator to define them afresh.
In addition to the genericity problem, there is also a problem of ambition creep. I produce something and make it work, but in a day or two it becomes obvious that this feature is confusing or inelegant. I have a great idea for improving it. So I do. And that improvement breaks something, turning a working inelegant application into a more elegant application that crashes. That sends me into debug and repair mode.
This develop-reconsider-revise rhythm isn’t the only possibility; one can do more thorough initial planning. I sometimes do. But I more often jump into development with only roughly formulated ideas, and then there’s backsliding along with the progress.
I’m not willing to claim that more thorough initial planning is always better. I respect it, but the most difficult problems seem to exist in both scenarios, and attacking them early by starting ad hoc may help solve them sooner. In any case, progress has eventually been outrunning regress. In a few days I may be ready to release the zeroth version for you and others to test. “May”, I said.