mrry (Happy New Year)
Blog Escape Velocity 7/Apr/2005

I present to you a software development vignette. I know for a fact that many estimable developers read this (if you're reading this, you probably are one), and I would be interested to know at which point you consider this story to have gotten silly. Okay then? Onwards!

It started with a daft idea. I have the house to myself for the next week, and those of you who know me will know that I'm hardly the most domesticated person. Ready meals are consumed; unwashed dishes pile up; underwear goes unchanged. Perhaps inspired by the wealth of on-line statistic-gathering sites, such as Audioscrobbler (via Steven), I thought it would be jolly to have a little scoreboard at the side of my blog that keeps track of my progress as the week goes on:

Time since last dressed28 hours 7 minutes
Ready meals consumed3
Clean crockery in house0

You get the idea (and, presumably, you also realise that I would never deem this worthy of inclusion on the blog, despite all of the other oomska). It struck me that it would be quite nice to have a little always-on-top desktop app that I could use to maintain these statistics. Finally decided to put on a new pair of boxers: click "Reset", and it would be reflected on the web.

So I came up with an idea for a simple Java/Swing utility that would let me keep track of these things, create an HTML fragment, and upload it to my webserver via FTP when it changes. Obviously, there's no point in limiting the program to this ("No point at all," I can hear the wags opining), so why not make the fields configurable? Not a problem.

Of course, this could have applications beyond a simple list of key-value pairs. Perhaps the same software could be used to create a "Now Playing" sidebar. Or even something relatively static, like a blogroll. Each would require a different UI, so that could be made pluggable, each generating the appropriate HTML fragment.

Of course, there is no need for the system to limit itself to using FTP for transfer. There are a variety of equally-appropriate uploading methods, such as the Atom, Blogger and MetaWeblog APIs, or it might be preferable to send updates by email, for example. So the transfer code should also be pluggable!

At the moment, what do we have? Some abstract code that generates an HTML fragment, and passes it to some more abstract code that will somehow transfer that HTML to its final destination. Could. Do. Better.

Why should it only generate HTML? Take the above example of a blogroll. Based on the same underlying model, it might be desirable to generate HTML, OPML, JavaScript or even LaTeX. So, for each kind of data model, we could have classes that render the data in as many formats as desired. Suddenly, what started out as simple and concrete becomes complicated and abstract.

A fundamental limitation remains. All updates must be carried out via the GUI. We might want to allow plug-ins in different applications running on the same computer (such as iTunes or Winamp, for the currently-playing notification) to initiate an update directly, using inter-process communication. We might even want to be able to make updates over a network, which creates some interesting possibilities involving mobile devices. Why not, then, remove the UI altogether and replace it with a headless RMI server that maintains a mapping between particular data models and transfer instructions? Or go the whole hog and implement the system as a web service, with all communication using SOAP? And, once we consider web services, it might also be necessary to consider having a multiple-user system, with the attendant added complexity.

So, there's no question (thanks to an XML-based relative of Godwin's Law) that the final position was very silly indeed. But I'm curious as to your opinion: at which point in the above did I become an Architecture Astronaut?




Gary Fleming said:
Christ, Derek. Didn't XPing it last year teach you anything? :P The simplest thing that could possibly work, and all that. Keep the hardcore abstractions out until you have a use case for them.

Steve said:
Right after you'd abstracted out the output data type.

Well, ok, I suppose have two answers to this: the first is that you instantly became an 'architecture astronaut' the moment the design progressed immediately beyond what it was required to do (take some inputs, make some HTML, and transfer it). No abstractions required, just a simple -- if very concrete -- piece of code. It would have done this particular job as well as any other solution.

The second opinion is that abstracting out the UI, the inputs, the output format, and transfer method isn't too difficult, so the additional effort to make it work is reasonably minimal.

The minute we're talking RPC or web services, we're really quite far beyond the original idea (which was essentially a clean-boxers counter), and we're talking about something that's actually getting reasonably complex. The actual functionality would be buried within a mountain of fluff just to make it all work :)

Of course, if the input/output/transfer blocks were sufficiently abstract, it should be possible to design out from centre and have an input plugin which handles all the RMI stuff, so the core functionality need not be altered. Also a UI which uses RMI to display state; another which is capable of calling other input code to update state (as per the original problem).

I'll stop now.





Please enter the number 1038 in the box below:

CommentsTell a friend about this page

Your Name

Your E-Mail

Your friend's E-Mail


< # Scottish Blogs ? >
Technorati Profile
Listed on BlogShares

Subscribe to the mrry RSS feed
More about RSS.
Trackback URL for this article: