Journler: Blog

The Proxy Application: Strategies in Software Development

June 25th, 2007

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.

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.

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