Well, with the Dow making its biggest single-day point gain ever today, maybe things aren’t going to be so bad after all. However, the economy is still on everyone’s mind these days, especially us independent consultants. Will shrinking demand for development services cause our business to decline, or will hiring freezes and tight budgets cause IT managers to look to variable-cost options like consultants and small development firms to keep key projects alive? Time will tell.

In case it’s the former, I’ve put together my predicted top ten growth industries for 2009, so we can all focus our limited resources wisely:

1. Brisk trade in gold, guns
2. Generating electricity for Bartertown
3. Foraging for nuts and berries
4. Being a Democrat in elected office/Not being a Republican (tie)
5. Repurposing credit default swaps into lightweight, waterproof shelters
6. Issuing public guarantees of underperforming bank assets/nationalizing the banks (tie)
7. Innovative financing methods to enable less-creditworthy borrowers to participate in the dream of home ownership, only in this case the dream is a blood-chilling national nightmare
8. Law practice specializing the the raft of rushed and poorly thought-out regulations about to be imposed on the financial industry
9. Fix and flip!
10. Providing Agile training and coaching at recession-sensitive prices to give businesses the tools they need to remain competitive in the face of shrinking budgets and to position themselves for success in the recovery, following Tim Bray’s recent suggestion

With so many options to choose from, 2009 could still really be an exciting year. As for me, though, I think I’m going to go with #10. Who’s with me?

At the DOSUG meeting last night, Matt Quinlan talked to us about his company’s product, Appcelerator. Appcelerator seems at first blush to be another JavaScript framework wanting to make AJAX and UI widgets easier, but actually does have a pretty neat spin on the problem that makes it something more than just another dōjō or jQuery. Appcelerator brings delcarative, remotable messaging to HTML. Put another way: the Observer pattern is back in your web UIs, and it misses you.

Early in his talk, Matt laid out the competing philosophies in the RIA space: to wit, plug-ins vs. the open web. These terms themselves are a bit tendentious (whatever is the opposite of “open” can’t possibly be good), and some of his arguments in favor of the open web were a bit thin, but at the end of the day I am with him here. Despite the power of the Flash plugin to deliver pixel-perfect UIs, cross-domain networking, and snappy user interaction with impunity, I still think HTML, CSS, and JavaScript are the best way to go most of the time. Call me a masochist.

Appcelerator includes some nice UI widgets and a framework-agnostic means of wrapping others’ JavaScript- or Flash-based UI widgets with a consistent API, but the talk was not about the widgets. The real value of Appcelerator comes in its in-browser message bus. Using nonstandard HTML attributes in your markup (something like <div on="click then l:show.box">...</div>), any of a large set of DOM events, key presses, mouse events, drags, drops, etc., can be published to a message bus running in the page in JavaScript. Likewise, any scriptable element can be delaratively advised to subscribe to messages in the bus. Thus HTML elements become Observers of an impressively generalized stream of events in the browser, and you are free to think about your UI at a level of abstraction bordering on the appropriate.

But wait, there’s more! The message bus isn’t constrained to the browser alone. You can publish messages to remote endpoints, which in the case of Java are consumed by annotated POJOs on the server (presumably through the agency of a canned servlet-cum-Controller you’ve mapped in your WAR). Back-end services are responsible only for returning JSON data, which is more or less automatically consumed by the Appcelerator front end according to some friendly-seeming naming conventions and the message subscription declarations already described. This is cool in the extreme.

This architecture has several positive implications. Chief among them is that your HTML pages become an entirely static resource, able to be served from a vanilla Apache instance disconnected from Tomcat, JBoss, WebLogic, the Black App Server of Mordor, or whatever. Your code does not render HTML anymore. Further, it becomes easy to mock back-end services in pure JavaScript. This allows front-end developers to write a complete and functional front end user interface—an artifact which is not a mock in any sense of the term—while easily mocking the back-end services by including a single JavaScript file. This JavaScript mock (really just a bunch of functions returning some JSON) then becomes the ultimate Agile spec document to be consumed by the back-end team one iteration at a time. It’s like the product practically builds itself.

And hey, as an aisde: some Appcelerator ninja should suggest a convention for this mock file, perhaps using JavaDoc-like comments that could easily be processed at build time into a publishable HTML spec document for quick reference. The code itself shouldn’t be too hard to read, but this extra step would be a nice touch.

Matt also talked about tooling a little bit, but with Appcelerator’s embrace of the open web, the tooling question becomes less important as a part of their value proposition. They can assume that we all have tooling we like for building HTML, CSS, and JavaScript—or perhaps more to the point, tooling we hate, but tooling we at least can call our own.

Appcelerator  was founded and is advised by veterans of the open-source world, including Matt himself, who was Employee 31 at JBoss and an early hire at Appcelerator. The company’s site puts forth the image of an open-source startup, but there is no mention of any way to give money to them, and Matt was coy on this question when I asked him. Given the recent tremors in the Enterprise Java community caused by Spring Source’s changes to their support policy, I feel a new sense of caution on this front. The product is licensed under Apache 2.0, so there’s no questioning its open-source-ness, but I’d still feel a little more relaxed about trying to adopt it for a future project if I knew how the company planned to make money some day. Now, don’t get me wrong; I love philanthropy, but the knowledge that somebody, somewhere is trying to make money from a product I use still gives me a certain sense of comfort, as if I need not speculate about future motives or present sources of funding. It makes sense that Appcelerator would be giving things away with abandon now, while trying to grab market share, but I’d recommend that they modify their messaging to include something about their future business plans. It would just give us a warm fuzzy, is all.

Notwithstanding that minor note of caution, this is a really impressive product that I’d like to try to take for a test drive as soon as I can. I’m very glad to have seen Matt’s talk.

Well, it pays to consult the thought leaders on this one. I’m told Ken Sipe does one-weak sprints, when he’s not busy piloting his single-engine plane deep into the bush on an obscure errand somehow related to an enterprise SOA deployment. Jared Richardson prefers a more moderate two weeks—life just has a slower pace in the South—and of course there’s a whole slew of lesser Agilists who claim you need a lavish three or four weeks to really find your stroke and make a productive team.

Of course, it all depends on what kind of project you’re talking about. Because for software, sure, two weeks is great, but if you’re taking advantage of amazing late summer weather and a few pleasant weeks on the bench to do some regrading of a troublesome patch of back yard, about two hours seems to work well.

Just saying, is all.

My JavaWorld article, Writing Software With the Grain: Exploring the Humanity of Agile Methods, is up! This is my first publication in anything bigger than a blog.* Dorky as it is, I’m pretty pumped!

The article explores several common Agile practices—to wit: user stories, lightweight documentation, and iterations—that happen to align well with normal human behavior given the kinds of creatures that we are. There is, you might be thinking, a host of philosophical assumptions that underlie this sort of reasoning, which I would be only too pleased to discuss over drinks sometime if you’re local.

I had to pick a limited number of Agile practices for analysis in the article, but I think there is more to the story than the three I’ve identified. A good example would be Extreme Programming’s Sustainable Pace. The opposite of Sustainable Pace is the discipline of death-marching developers just hard enough that they don’t quit, but hard enough that we squeeze maximum productivity out of them. If developers were impersonal units of software production akin to machines, this would be the right way to manage them.

The most obvious objection to this is the law of diminishing returns, or the idea that each marginal hour worked is an increasingly fatigued, and correspondingly less productive, hour. While there is certainly some truth to this, I think we’re forced to grant that we actually do make more progress when we work more hours. Everybody knows crunch time, and every honest developer is forced to admit that the crazy schedule of the final push to the finish actually make a difference—at least up until the time the hallucinations start, which in itself can be kind of fun, as long as it’s your coworkers doing the hallucinating.

The best objection to overwork isn’t a utilitarian one; rather, I would argue that the notion of Sustainable Pace is grounded in the right relationship between work and the other activities in human life given the kinds of creatures that human beings are. It is good and right for us to spend a certain amount of our time following some kind of economically productive vocation out in the commonwealth. It is also good and right for us to spend some amount of time with friends or family, some amount of time sleeping and eating, some amount of time standing in line at the DMV, some amount of time inside, some amount of time out-of-doors, etc. For most people, work might take up a plurality of the pie, but it should not be a significant majority. It is in our nature to spend our time in a variety of roles activities, of which work is but one part.

“The Humanity of Sustainable Pace” could definitely use a more detailed treatment than I’ve given it here, but my point is to illustrate that there is more to the topic than my article covers. I’d love to see the community do some more thinking along these lines. The trick is to realize that human beings are a particular kind of thing—we implement a common base class, if you will—so the practices and methods we develop in our vocation should respect that class’s semantics. The notion that we are uniform production units that can be squeezed into whatever organizational structure and management schema we choose is destructive not just to the ontology of the human person, but also to the well-being of the people on our teams—people who may well be our friends, and people whose healthy vocational context is certainly our responsibility.

So let’s think some more along these lines. Agile is doing great things, and hopefully more great ideas can follow from it.

---

*This is technically untrue. In sixth grade, I wrote to the middle-school science magazine Current Science with a proposed design for a perpetual motion machine, which was in essensce a really, really efficient electrical generator. They redrew my diagram and published it, asking the readers if they thought it would run forever. Widsom of the crowd, baby! Except in this case, perhaps not.

Welcome to the professional blog of Tim Berglund, founder of the August Technology Group. I’m no stranger to blogging, but this represents the first time I’ve committed to writing about software development exclusively. Since inaugural posts filled with a bunch of ambitious plans for my extensive future content, or high-minded declarations about how I’m going to “explore the medium,” or ever at any point putting in print the words, “Let the conversation begin!” are all just a wee bit 2004, let me just assume you know why I’m blogging and tell you a little bit about myself.

I’ve been developing software professionally since 1992, two years before I graduated from college. The first seven years of my career were dedicated to embedded firmware and simple Windows applications, usually the handmaidens of some firmware project or other. In about 2000, I discovered Java and web development and have not substantially looked back since—although I don’t mind admitting that debugging software with an oscilloscope and a soldering iron has a otherness to it that we are hard-pressed to duplicate in web development.

In the eight years since, I have developed internal web applications, ecommerce web applications, B2B integration software, specialized vertical search tools, and other great code living mostly in the world of open-source Java. Recently “Java” has included Groovy as often as not. This is a good development for the community and for me.

I started the August Technology Group in the summer of 2007 so I’d have a platform to serve customers more directly through execution, training, and mentoring in the kinds of software development I’ve done using the agile methods I’ve learned to apply. I’m starting this blog now so I can talk about software as the kind of thing I think it is: a fun, challenging, rewarding, deeply human enterprise surrounded by a richer intellectual tradition and more interesting intersection with the liberal arts than we often think.

Which isn’t to say I absolutely won’t post neat tips and tricks about how to do odd things with regular expressions in Groovy or how to configure Jetty to do thus-and-so. It’s just that I might wax philosophical on occasion as well. For those who know me, this is no surprise. For those who don’t know me, I look forward to making the introduction and getting to know you as well. Thanks for reading, and thanks for subscribing.