Software Engineering

Reactions to NeoVictorian Computing

One of my inspirations as a professional is a man named Kelly Mehler, the father of a childhood friend of mine, who runs a small furniture-making shop and teaches woodworking. He’s eschewed mass production and has made a successful and profitable career out of hand-making furniture that is beautiful both in its visual appeal and its utility. Though he certainly can’t produce furniture as cheaply as a large operation in a lower-wage country, his business model is under no threat from such competition. And he can be proud of his work every day. These are things I’d love to be able to say about my own career.

So, it’s with that context that I stumbled upon Mark Bernstein’s recent posts exhorting a NeoVictorian movement in computing. (No, I wasn’t searching for cosplay photos.) Suffice it to say that I’m sympathetic to his central thesis that the rhetoric and practice of computing in “the enterprise” can be alienating for the practitioner and detrimental to the practitioner’s creativity. Writing software within a large corporation is not always subject to the criticisms that Bernstein makes, but the risk is there.

For many software engineers the solution is to participate in open-source projects which allow them to work on ideas that their dayjob doesn’t give them a chance to do. For others, the solution is to take a run at a startup idea of their own. And then there’s Bernstein’s approach, suggesting that perhaps the whole target of enterprise computing is flawed. I think that he’s right to suggest that there exists a whole class of software that might be built for the individual knowledge worker, and which offers ISV’s the opportunity to exercise their creativity.

However, it’s clear also that the core of enterprise computing will always offer a lot of unique engineering challenges and pay a lot of software engineers’ salaries. I think that, at a minimum, working in that environment successfully requires:

  • actually caring about the business/industry in which you’re working
  • being part of a talented, collegial and motivated team
  • knowing what you want to work on and being direct about it
  • being agile (small ‘a’) enough to not get too rattled by the fickle nature of business requirements
  • having the guts to speak up (diplomatically) when you think an idea is just completely wrongheaded

Clearly, some of those attributes are social rather than being strictly technical. And some of them are attributes of the organization itself. So we as software engineers need to pick our employers carefully, and recognize that that we need social skills as well as technical ones.

Software Engineering

SourceForge: Hot or Not?

Wonderful, now that I’ve set my little code project up on SourceForge, Tim Bray comes along and bursts my bubble. The consensus among his commenters seems to be that Google Code is the better place to put your projects. All that work going through SourceForge’s FAQs and help documentation just to discover that I’ve lost cool points! Ah well, the most labor intensive part of getting set up actually had nothing to do with hosted source control — namely, reorganizing the project to use Maven. I think if I need to move the project it will be easy enough to do so, although SourceForge does have some draconian rules about never removing files that have been posted. In any case, I will give Google Code a closer look in the near future.


Moving KeyStone into a SourceForge project

I’ve made a good start on transitioning KeyStone into SourceForge. The initial release that I’ve been hosting from this site is now available to download through their system, and the SVN repository is up and running. Additionally, I’ve reorganized the source tree, transitioned to using Maven as the build system and fixed a few bugs on the way to another (hopefully soon) minor release. Here’s a link to the SourceForge project page.

Software Engineering XML

Quick impressions of WADL and REST services

When I came across the WADL spec 6 months or so ago, it seemed to me that it was reaching for desirable goals. I’ve done a number of integration projects using SOAP, a few involving more ad-hoc XML-over-HTTP designs, and even a couple recently that more consciously strive to be REST-ful. Through those experiences, one of the things that I have liked about SOAP is that one can exchange a WSDL file with another organization and get server-to-server integrations moving along pretty quickly. Furthermore, if you’re used to reading WSDLs and the author wrote it sensibly, you can get a precise understanding of what data is going on the wire, and generally what’s involved in using a service in a shorter time than poring through prose documentation. Maybe it’s some form of software Stockholm Syndrome, but I’ve grown to like the ol’ WSDL. The larger WS-* family of hydra-headed standards gives me the same headaches that it gives others, but I do think that it’s nice to be able to hand over a machine-processable description of your system’s API interface which enables remote clients implemented in nearly any programming language on any OS to access its functionality.

So on the basis of recently re-reading the WADL spec and writing a couple of test WADL documents, I’m pretty confident in saying that WADL has at least achieved the basic goal of applying the WSDL concept to the REST service world. On top of that, the spec is lucid, succinct and highly readable — it’s like poetry compared to any of the WS-* specs.

There is a fair amount of criticism of the WADL effort from the RESTafarian camp, but none of it actually takes the spec to task for being poorly done. Rather, the criticism seems to center around the idea that the whole notion of a formal description language for REST applications is misguided from inception. Some of the highlights of that criticism come from Aristotle Pagaltzis, Mark Baker and Dare Obasanjo.

I think Aristotle’s remarks are perhaps the most valid — maybe a different sort of specification (along the lines of the ATOM Pub. spec) is needed to go whole-hog with the REST approach. But on the other hand, I’m willing to bet that 95% of the people who turn their nose up at using something like WADL will then turn around and write their plain old human readable documentation in such a way that it describes exactly the same things that WADL describes: what URLs to hit, what parameters to pass, what data to expect in return, etc. Because so far that’s what I’ve seen in APIs such as the ones offered by Flickr, Facebook, etc. To my mind, having a succinct, easily machine-processable form of documentation for your code seems like a win.


Site Redesign Complete

After much CSS-tweaking and WordPress-wrangling, is back with a slightly new look. Perhaps it’s not so much complete as much as I just decided to stop and get some other things done. So, here’s to getting other things done!