For the last year or so within the Guardian Unlimited technical team there’s been a continual low-level question being debated: what technology should we use to build GUI tools for our editors, and in particular should Ajax play a part? It’s a debate in which a technology manager has a rather different perspective from that of a developer. In this article I want explain those considerations.
Why is this even an issue?
It probably seems odd to ask about a GUI technology, since you would imagine — rightly — that we’ve already built an awful lot of tools for our editorial teams. They have tools to write articles, create quizzes, manage podcasts, and much more besides. But it’s come about recently due to a confluence of events: the rise of Ajax, and the realisation that most of the tools we built five years ago are Ajax-a-like tools without us having come up with the catchy moniker; the oft-discussed integration of newsrooms, and the consequential comparison of our home-grown tools with professional systems such as Adobe InCopy; and the general desire to upgrade and improve anything that’s a few years old.
Despite having Ajax-a-like tools in-house, the question as to whether we use Ajax is still pertinent because the frameworks and techniques available now mean we’re talking about a very different codebase and approach to what we’ve developed historically. We are in a position to decide on a technology which is actually new (Swing, Flash, etc) or effectively new (newer Ajax techniques, or a readily-available Ajax framework).
In some organisations this wouldn’t even be a question. Many BBC journalists use in-house Visual Basic applications, and if Guardian Unlimited was a Microsoft shop no doubt we’d be doing the same. Maybe we’d move from VB6 to VB.NET, but the core technology would remain: native Windows applications with native Windows GUI components.
Why is the technology manager’s view different?
Everyone in an organisation has their own perspective. Developers need to focus on getting the immediate task done; project managers need to focus on getting the immediate project done; I find that more than most other people I’m thinking about operational issues. How will it pan out in the long term? Where will it leave us 12 months from now? Five years from now? How will we grow with this technology in place?
Creating Ajax applications might be fun and cool, but there are plenty of more serious issues to consider. Here is my checklist of considerations…
Check: Minimise the number of technologies
There’s only so much an ordinary person can really be good at. Minimising the number of technologies you deal with means that you get to become expert in those, and so ensure you get the most out of them. If you use one technology everywhere, then whenever you pick up a skill or insight in one project every subsequent piece of work benefits.
By contrast, spending a relatively small amount of time on a particular technology means that you probably don’t get to use it in the most effective way. You may have been using Perl, say, over many years, but if that use has only been intermittent then you’d never learn the quirks, never learn the efficiencies, and never commit time to making sure you had a good, reliable Perl environment in which you could consistently produce really reliable code, and have the motivation to keep that environment up to date.
On the other hand, if you commit to using a technology in one place, for one job (if we were to use Ajax, say, on the front-end website) then it’s too late — you’re already infected. The technology is already in use, and you’d better get au fait with it pretty quick. But you’ve still got some choice. You could still decide that it will only be used for that specific role, within strictly defined parameters. Nevertheless, that’s a much harder rule to enforce. You’re still at the top of a slippery slope.
Check: What is the future of that technology?
It’s of great importance that any software developed doesn’t become legacy — or at least avoids being legacy for as long as possible. Choosing a technology today that won’t get updated tomorrow means you won’t get bugfixes for it, and you won’t be able to find new libraries to deal with the changing technological landscape.
I once worked at a company where a core Unix server product was built around Netscape Enterprise Server (“voted best of 1998”). It was probably the right thing to do at the time, when Apache was just emerging, but it turned out it didn’t have a future, at least not for our purposes. It became increasingly hard to sell into companies and eventually we had to embark on a significant rewrite programme to recover lost ground.
Ajax is the technology du jour, but where will it be in two years’ time? Swing has the stability and backing of Sun Microsystems, but will the ascendency of Ajax mean they take their foot of the accelerator as they focus on Ajax? You need to make a good guess at these and other market questions to ensure your software isn’t based on legacy software.
Check: How stable is the technology?
This is most pertinent to those technologies that are newer or developing rapidly.
I’ve seen a project built on an emerging graphics framework that changed every week. Each week the lead developer would spend a day updating his version of the framework from the trunk, fixing all the bugs and rewriting great swathes of his code because it used calls since removed or replaced.
Swing, of course, has never had a problem with lack of stability. And that’s also a problem, which is why we must also ask…
Check: How current will it remain?
Say what you like about the graphics framework that changed every week: it sure was up to date. By contrast, if you report a Swing bug to Sun tomorrow, what are the odds on it getting fixed in time for your next release?
Demanding stability and currency is of course a bit cheeky, but unfortunately they’re both needed. It is often possible to attain them, though — if your technology supplier is committed to backwards compatibility. This is a creed that Microsoft has stuck to so vehemently for years, and which Sun has applied stringently to Java… so stringently, in fact, that they created a generics solution for Java even more compatible than Microsoft’s generics solution for .NET.
Check: How much support does it have?
Whether the technology can do the job is one thing, but you must also ask if it does it well. Does it have IDEs? Test frameworks? Deployment systems? Libraries for XML, RPC, TLA, ETC? These are usually things you can build yourself, but, really, are you going to?
Support also extends to the wider community. If you find a bug, how quickly will you be able to get help or otherwise find a solution?
Check: How ubiquitous is your new technology?
Another question for any new technology is how widely you can apply it. If you introduce a new technology you’re likely to find yourself using that to solve many other problems, even if it isn’t the most appropriate choice. You may find yourself extending an application in a way the underlying technology wasn’t really designed for.
I recall using the Informix Web Datablade for a project which was ostensibly a series of intelligent web pages. But as subsequent prototypes were delivered and new feature requests came in it became apparent that this was absolutely the wrong choice for that particular job. Of course, by then it was too late, and after a while the project was politely and calmly shut down.
Nobody wants to choose the wrong tool for the job, but you also need to look at future jobs and see what will be needed there.
Check: What is the base skillset?
This is the reason you don’t see much mention of Flash in this article. You can create great GUI applications in Flash (check out the Groovy.com demo) and Guardian Unlimited has terrific Flash skills in-house — see our interactive guides. But those guides come from our design team, not our software development team.
When considering any new technology you need to be sure about the skillset you’re starting from. Sure, everyone wants to learn Ruby. Sure, Ajax looks great on a CV. But what are the skills your team can really learn well? What does it take to be an expert? Because delivering an enterprise grade application means you need to be an expert, and there’s a world of difference between walking through the tutorial and creating your own application for a demanding client with a deadline.
Check: What is the future skillset?
This issue applies not just to large technology choices, but smaller ones, too. I’ve been involved with an application where the data feed was SGML — a promising technology once, but it quickly fell to XML and no new developers arrived with SGML skills. After the initial developer moved on no-one really knew how the application was supposed to work. We rewrote it eventually, but only after an awful lot of pain.
So finally, then: Ajax or Swing?
Back to the beginning, then: Ajax or Swing? Naturally, the above checks don’t settle the matter, but I hope they give a good idea about the kind of things that need to be considered.