Accomplishment Paralysis
Jul. 1st, 2010 10:22 amFor the past three days, I've been working about an hour a day on a little project that I launched a few years ago and never finished. At the time, I didn't have either the technology or the knowledge to work on it successfully, but now I do: I have a reliable application server for handling and storing the data, and I have a hug jQuery knowledge base that lets me construct the RIA front-end.
In the past three days, though, I've gone through four different revisions of the whole framework: is it server-based, with a light front end, or client-based, with a full-duty front end. I'm now at the point of having two back-ends: a functional one, and a theme-oriented delivery one. I'm also working on two front-ends, one functional and one theme-oriented. (It's a little weird in that the back-ends are compositional; the front-ends are inheritance-based.)
The idea is that the back-ends (1) deliver the HTML, Javascript, CSS, and graphic assets to display the program, and (2) handle storage for the program, while the front-end components (1) handle transactions with the storage engine and (2) drive the visual interaction. I'm designing the visuals around the Palm-Pilot/iPad model, where the convenience of input is most focused on those things you'll be entering frequently. Eventually, these pages could even be standalone, the thematic part downloadble and the functional part supplanted with WebDatabase client-side storage.
I can't tell if this constant stop, go back, revise, and start over is part of the necessary development iteration process, or if I'm using analysis paralysis as a way of expressing a more fundamental problem-- accomplishment paralysis.
Because once I've finished this thing, what do I do with it? I set out to repair a fundamental problem with my personal workflow-- not knowing what to do next. (Irony is a lifestyle, you know.) One of the things I wanted to fix with this project was to create a landing page with dynamic lists. I started with very concrete objects (Contexts, Roles, Projects, Tasks -- as per my current design) and devolved to a single thing with a tree-like storage pattern. I started with concrete equivalents on the client side and have now devolved those same abstractions for the functionality, with the concreteness being encapsulated only in the functional javascript component.
In one sense, this is satisfying. I've identified where the program needs to go from being abstract to concrete. But dammit, I should be done by now.
I can't help but neurotically complex about what I do with this project when I'm finished with it. Do I put it up in a public space? Do I let other people play with it? After all, there are plenty of nice personal landing pages, but most of them are about being in contact with your social network. I want one that's about what I'm going to accomplish. Maybe other people would like it as well, but that would mean switching from creative development to business maintenance.
And I don't know that I'm cut out to be a businessman.
In the past three days, though, I've gone through four different revisions of the whole framework: is it server-based, with a light front end, or client-based, with a full-duty front end. I'm now at the point of having two back-ends: a functional one, and a theme-oriented delivery one. I'm also working on two front-ends, one functional and one theme-oriented. (It's a little weird in that the back-ends are compositional; the front-ends are inheritance-based.)
The idea is that the back-ends (1) deliver the HTML, Javascript, CSS, and graphic assets to display the program, and (2) handle storage for the program, while the front-end components (1) handle transactions with the storage engine and (2) drive the visual interaction. I'm designing the visuals around the Palm-Pilot/iPad model, where the convenience of input is most focused on those things you'll be entering frequently. Eventually, these pages could even be standalone, the thematic part downloadble and the functional part supplanted with WebDatabase client-side storage.
I can't tell if this constant stop, go back, revise, and start over is part of the necessary development iteration process, or if I'm using analysis paralysis as a way of expressing a more fundamental problem-- accomplishment paralysis.
Because once I've finished this thing, what do I do with it? I set out to repair a fundamental problem with my personal workflow-- not knowing what to do next. (Irony is a lifestyle, you know.) One of the things I wanted to fix with this project was to create a landing page with dynamic lists. I started with very concrete objects (Contexts, Roles, Projects, Tasks -- as per my current design) and devolved to a single thing with a tree-like storage pattern. I started with concrete equivalents on the client side and have now devolved those same abstractions for the functionality, with the concreteness being encapsulated only in the functional javascript component.
In one sense, this is satisfying. I've identified where the program needs to go from being abstract to concrete. But dammit, I should be done by now.
I can't help but neurotically complex about what I do with this project when I'm finished with it. Do I put it up in a public space? Do I let other people play with it? After all, there are plenty of nice personal landing pages, but most of them are about being in contact with your social network. I want one that's about what I'm going to accomplish. Maybe other people would like it as well, but that would mean switching from creative development to business maintenance.
And I don't know that I'm cut out to be a businessman.