Broken Promises

There's a working group that just started up called the Thin Server Architecture Working Group (ok, it's just three folks that are getting together to discuss things, but it's a start). It looks like it's going to be a higher level discussion than related W3C activities (which are more focused on standards discussions). InfoQ has a good one page summary of what's out there for the working group today (which isn't much).

Here's my issue though... my current role is all about the delivery of a Rich Internet Application (RIA), and I have some fundamental issues with the standards and implementations today:

Storage of the "View" - The Thin Server Architecture Working Group is all about the idea of pushing the interface logic to the client. That's very good... but something needs to provide that logic to the client (hint: the server). They need to be sure to consider that part of the architectural models in their work.

Current Client Rendering Performance - HTML clients have some serious performance limitations today. DOM manipulation seems to have been considered a secondary performance goal until recently. Flash and Silverlight are certainly able to handle the visual aspects of the presentation effeciently, and they both offer opportunities for fairly effecient display logic to be imbedded, but I'd like to see the browsers step up their DOM handling efforts.

Developer Optimization - I know that many, many developers and architects look at the MVC model as being superior to the "everything in one block of code" model (I made that one up, but you know what I mean). That's absolutely true, but one belefit of the "everything in one block of code" model is initial development (not maintenance development) can be performed as a stream of thought. Because of this, many younger or less experienced developers will start to learn some very bad habits as soon as they start coding for the web. Tools for RIA development need to help with the seperation of logic layers (not necessarily the MVC model), and at the same time feel natural to code.

Standards and working groups are very important, but the most important part of any architecture, specification or design pattern is how they get implemented in the real world.

We have really short iterations in my organization… which is a blessing and a major hurdle. We try to be "agile" in our development cycles, but sometimes "agile" gets awful close to "chaotic". The problem that we have is that we are part of a "Service Delivery Organization", or an organization that is dedicated to supporting the customer's production environments. This makes it really hard to separate someone's legitimate production issue from something that is a legitimate problem, but has to be resolved through a new feature enhancement to the system.

The distinction between a "problem" and a feature request that needs to be added to our backlog is an interesting one. If we were able to follow the SCRUM methodology correctly (really at all), we would always be asking that these requests go through a "product owner" for each part of the system. My counterpart on the Analysis side of the team has done a wonderful job of trying to make this happen, and he has had some measure of success. However things still slip through the cracks and derail the team. I recently dedicated one developer a week, on a rotating basis, to the role of "maintenance" in order to try and deal with the need for quick turn-around additions to our software. Just like the attempt at moving all requests through a "product owner", this has had a little success and a little failure. We're constantly tuning how we react to "production needs", and we hope that we will eventually figure it out.

In the meantime, we find ourselves in a situation where the majority of our work (something like 70%) is broken up into projects that are one week of development and one week of testing. This is an interesting pace to keep up, as we are expected to be able to do a release once every two weeks. It doesn't mean that we are releasing major changes that often, but it does mean that there is almost always something going out to production on those cycles.

I mentioned the SCRUM Sprint because we have a very interesting model of one to two person projects constantly working in mini-sprints. I would be interested to know if any organization has found a methodology that can support turnaround times that are shorter than a month for mission critical systems… all the while maintaining a constant backlog of about 6 months of work (that's after dividing the effort by the number of resources that we can dedicate to it at any point in time).

Thin Server Architecture Working Group

When a SCRUM 30 Day Sprint is Too Slow

About

Archive

Get Updates