Are you ready for the 2010 XAF roller-coaster?

Recently (and maybe not so recently as all that too), customers have been voicing worries about the direction we've been taking eXpressApp Framework (XAF), some even going so far as to say there is none. Roman, Gary, Oliver and I had a long chat via email about the situation and decided that what was needed was a post about what we're doing, about the support in the company for it, and what you can expect in the near and middle future. In short: very rosy indeed.

First, a little historical background to understand where we're coming from. XAF development was started in early 2004, based on some work done on an insurance line-of-business project written in Delphi. From the start, then, it has been geared to real-life projects. The first goals were simple: create a persistent object framework and a WinForms MVC presentation framework. For one reason and another, the persistent object framework had to be done first — in essence building XAF from the bottom up — so that we could then test our MVC and business object layers as early as possible. When it was good enough for our purposes, we decided to release it as a separate product: eXpress Persistent Objects (XPO).

After that, obviously, XPO started to live its own life. It got its own team (the original designers, in fact), and much effort was invested to respond to feedback and to satisfy requirements from all customers, not just from the XAF team.

By late 2005, DevExpress' R&D were suffering from some growing pains: the developers were being spread far too thinly across all our product lines. We reorganized what we were doing, reevaluated what products we should concentrate on for the short term, and revamped the targets for the following year.  As a result, the XPO developers were moved back onto the WinForms team and, in time, they became responsible for new WinForms products. It was at about that time that Oliver joined us.

In early 2006, the XAF architecture was pretty much established, all the basic components were implemented, and so we released a CTP to collect feedback on what we'd done. The feedback was, to put it mildly, rather positive. Also in early 2006, an internal team successfully used XPO as a base for our internal systems (ClientCenter, sales system, SupportCenter), and used XAF as the backend UI. (In other news, I joined DevExpress right about the same time. Coincidence?) By the end of 2006, XAF was released as a part of the DXperience v2006.3 release.

During 2007, from v2006.3 to v2007.3, the XAF team were working on implementing various feature requests from customers who were trying to use XAF to create real apps. Also in the final release of the year, XAF got design-time support. In 2008, the team released various new small and medium-sized features and XPO finally got its own team back. Roman decided that the XAF architecture needed to be changed in order to abstract XPO, so the Domain Components (DC) approach could be possible. He started working on designing the DC technology describing what we needed to do as a series of posts (1, 2, 3, 4, 5, 6, 7). The first major refactoring, the type information system, was completed for v2008.3. I'd have to say that our original goals for XAF were finally met in 2008: make the simple things simple, and the complex things possible.

Also, at around that time, a year ago, I would say that XAF support and maintenance levels reached full bore. Some of our customers had reached the final cycles of their app development, so now we were getting a full range of support questions from the beginner to the advanced XAF developer.

At the end of 2008, we took stock of the situation:

• We had some strong momentum in the customer take-up of the product. Reviews and feedback were favorable.
• XAF needed many more improvements at every level in order to become a better business app framework.
• Even with its current feature set, we barely had enough resources to add new features, due to the support/maintenance bottlenecks.
• The team's desire to help out and implement customer suggestions often led to local hacks instead of beneficial changes that improved the overall architecture. (Roman's current WAG is that 30% of XAF code can easily be removed without any loss of functionality.)

So, changes were needed in 2009. The first steps were organizational, and mostly happened in the v2009.2 timeframe:

• We hired more developers. We currently have 24 people over both the XAF and XPO teams. (This number includes tech writers and support engineers too, note.)
• We put everyone in XAF on the same floor of the building. (Like, duh.) Everyone is now within reach of everyone else in the team.
• We split the XAF team into several subteams — Core, UI, Base, Data, App — to make code ownership easier and create better architectural boundaries.
• Andrew, one of our most senior developers, joined the XAF team in the summer. He spent quite some time with the new developers we were hiring doing research efforts on MVC and XAF so they could learn how we work, what we do, and what needs to be done and how.
• We started a series of design review sessions where the whole team analyzed what should be changed in order to reach new goals.

Now we all know that adding more people to a project or team does not immediately help. In fact, it does the exact opposite: it slows everything down at first. That's why XAF progress has been slight over the past couple of releases: lots of minor changes, no real major changes. Our main goal was to make v2009.3 the best version of the "old-style" XAF: that is, don't break anything, make many smaller improvements, and keep the radical changes for 2010. Since code freeze, we've been making many simplifying refactorings for v2010.1, basically anything and everything that will reduce complexity without losing functionality. XAF is now poised to take advantage of some stronger momentum.

With regard to 2010, we have to deliver on Roman's DC plans. The team is poised and ready, but this will inevitably mean breaking changes along with the new features and functionality. At PDC, we also demoed our first cut at the support for WPF in XAF: still a way to go, but a good first step (another that we didn't show off was an ASP.NET MVC proof of concept). One thing is certain, though: 2010 will be a faster ride for XAF than 2009 was. Are you ready to strap yourselves in and grasp the grip bars?

Free DevExpress Products - Get Your Copy Today