Journler: Blog

The Proxy Application: Strategies in Software Development

It’s over a week since WWDC 2007 and I am still reeling from my first exposure to the fascinating, jargon filled world of software development processes. What was probably a boring session for many of the attendees was for me a first step into the disciplines of project management and development methodology. I am eager to apply what I have learned.

Lex
Alongside Journler I am working on Lex. Lex picks up where Journler leaves off. If Journler is “entry based information” then Lex is project based documents. Journler was originally designed for journaling your life. Although the program benefits from recent features seen more commonly in information managers, Journler is not one by its nature. Lex is, and where Journler runs a single database, Lex is databases plural so that you can split projects up and deal with the relevant data in distinct groupings.

Development has, however, taken longer than expected. In a post two months ago I said I would need four weeks to produce a working version. It was a na├»ve enthusiasm. The coding itself isn’t so much the problem. My style is. I go about my work in an erratic way, jumping between features to see if they are all possible. I have reached a point where, although I am confident everything can be done, I am lost in a maze of half accomplished ideas.

Iterative Development
“Iterative” software development refers to a process which moves forward in short, repeated, independent phases. The steps involved in the development of a complete product — requirements analysis, design, coding, testing, and documentation — are compacted and micro-applied to every change made over a product’s lifetime. With each completed change an improved, fully functioning product is ready for release, even if it is not actually delivered.

I have decided to apply this approach to Lex. It is an opportunity to discipline my practice and ideally produce a better product faster. Hoping to add to iterative design theory, I will be adapting the process to fit the needs of this project. Rather than applying the iterative method to small changes built into the project as a single system, I am partitioning Lex into self contained, feature specific “proxy applications” and applying the iterative process there. The goal is to produce independent, fully functioning applications out of the many features that Lex brings together.

The Proxy Application
I am calling them proxy applications because during development they stand in for the corresponding features actually built into Lex. This differs from prototyping. I will not be developing models that demonstrate or test an idea. Instead, the process should produce applications, feature complete though highly focused on a single task. By isolating a subset of Lex’s functionality into a separate application, the proxy allows me to analyze, design, code and test that subset independent of every other. While one proxy undergoes real world testing I’ll be able to work on others without interfering with the first, and vice versa.

Lex is an extensible application from the ground up. Although I define the program’s core functionality at the outset, plugins are responsible for the actual implementation. Lex itself is tiny, a simple structure with hooks for the plugins. I believe that projects of this nature are especially suited to the use of proxy applications. Most of the proxies I have envisioned for Lex are simply wrappers for a feature expressed by one of the hooks.

Applying the Method to Lex
If this is all too abstract let me offer a concrete example. In addition to the regular and smart folders already familiar in Journler, Lex allows you to build spotlight folders which automatically collect documents on your computer. Support for executing this action is built into Lex, but the means by which you specify a folder’s criteria is implemented with plugins. This is the hook. Lex examines the document type targeted by the folder, e.g. PDF or Image, and loads the most appropriate plugin, permitting plugin developers to target files with custom metadata or taylor the existing set.

Spotlight folders concretely define one of Lex’s features. Following the proxy strategy, I isolate the relevant code and wrap it inside a proxy application. The proxy takes center stage during development. I do all my design, implementation, and testing on it. Furthermore, the proxy is a complete application in itself. In this case I’m calling it Smarts. As soon as Smarts reaches a mature stage I intend to release it as a standalone application. Real world testing will verify that the feature performs as expected, at which point I can integrate the code back into Lex itself.

Where It All Leads
From the user’s perspective it will look like I’m not working on Lex at all. Instead, you’ll see the release of a number of simple applications with strongly defined feature sets. But behind the scenes I am actually combining each verified proxy into a single, whole application: Lex. The method should allow me to establish the code for each feature more quickly as well as more efficiently test and debug it. Ideally, before a beta of Lex is even made available, most of its functionality will have been tested and verified. The end product is one of higher quality that is produced more efficiently.

That’s the hope. Lex has just become an experiment in software development. It’ll be interesting to see how this works out.

3 Responses to “The Proxy Application: Strategies in Software Development”

  1. NovaScotian Says:

    Sounds like a very intelligent way to do a design (and that comes from a guy who taught an Advanced Engineering Design grad course at MIT for 8 years and worked for several years on a concept we called “Axiomatic Design”).

    This latest post convinces me that with the AppleScript savvy you discussed once before (one of your proxy plug-in apps, I surmise), Lex will be a must have for Scripters, replacing Daniel Jalkut’s now aging FastScripts and Spotlight for finding stuff. Though FS has an entirely different basis, Lex, with a little scripting, can be made to do everything it does and serve as the basis for your scripting projects. I suspect coders in other languages will feel the same.

    Looking forward to it.

  2. Phil Says:

    I’m actually still trying to decide if AppleScript will make it into the 1.0 release. I can’t do applescript as a proxy in itself because scripting applies to the data model which guides the project as a whole. I think I am, however, going to try to implement script support in some of the proxy applications on a small scale, just to make sure I can get it working before adding it to Lex proper.

    The problem is Core Data. AppleScript was tough to implement in Journler because scripting is just plain hard. Well, it’s doubly hard with a Core Data application because of “ordered” and “unordered sets.” AppleScript uses ordered sets, but Core Data deals exclusively with unordered sets. For folks who aren’t sure what we’re talking about, think of a bag of apples. AppleScript pulls the apples out of the bag in the same order every time. Core Data just gives them to you in any old order.

    Going back and forth between ordered and unordered data is apparently a pain in the butt. I have to implement a middle man which gets the apples in any old order but puts them into the expected order before handing them off to AppleScript. Thankfully a long time coder has provided a sample project which demonstrates how to do it. I already have my hands on the project and have been going over it.

    Keep your fingers crossed!

  3. dancingbrook Says:

    Can’t wait to see it and wish I had time to offer to help.

Leave a Reply

You must be logged in to post a comment.

Copyright © 2006-2007 Journler. Some rights reserved       Contact: Phil | Evan Agee (Webmaster)