This post is an attempt to help justify the sometimes seemingly unappreciated efforts of good application architecture. Sometimes project managers/clients can question time spent on architecture and it can be hard to bring out appropriate explanations on the spot. This post intends to be a reference for the next time someone tries to convince you its wasted effort.

One of the advantages of RIA technologies such as Flex are that they are quick to develop. This point is further emphasized by many of the tutorials and screen casts that demonstrate seemingly complex tasks being completed in a matter of minutes. Unfortunately this can give off the misconception that RIA development is easy and that clients should expect all applications to be built in such an easy fashion. The reality is that with larger requirements comes a need to plan and organize your application more thoroughly than simply laying out a few components and setting some data sources.

Other resistance can also come from new users to a platform who often see architecture, frameworks and best practice as overly complicated noise "why can't I just put all my logic on this button's click handler?" is a common view point and can be tricky to justify at first.

I would however argue, that someone new to programming or a particular platform would be better off using the jump-in and go approach as an appreciation of complex architecture will be very hard to grasp until you've experienced some of the issues they address. However for developers who are looking to evolve their skill set or for the stubborn who fail to see the benefits here are a few notes on why a good architecture matters in RIA development (and development in general).

Consistency

I don't think many would argue with the DRY (Don't Repeat Yourself) principal. Even with the "logic-on-button" approach it's still relatively easy to stick to this principal by simply moving any duplicated logic into a separate function et voila, DRY done. However, as your application grows to more than a single view, our function needs to either be made public and accessed from other views (not good - our original view will always need to be available) or moved out of the current view into it's own class (better). Multiply this complexity several times and before you know it things are very messy and phrases such as "spaghetti code" and "needle in a haystack" will soon be springing to mind. With some fore-thought put into your application architecture, every function has it's place and once familiar with that architecture anyone can instantly "just know" where a function will exist.

This consistency also makes programming decisions much easier and quicker, with less re-factoring required at a later date. It doesn't take long for these benefits to outweigh the fact you didn't just dive in and start writing code on the first UI component you laid down and the phrase to mind will be "a place for everything and everything in it's place".

Team working

No one ever likes to inherit another developers code. Ever. Poorly architected code can lead to hours or even days of lost man hours trying to figure out what code is where and for what purpose. Two developers almost certainly wouldn't just choose to implement some functionality in exactly the same way and when implementations need to be shared time is spent discussing what code is doing and why it is so. Time is much better spent ensuring that all team members are familiar with a common architecture and are then more likely to code in a similar manner. This increases cohesion between the team, helps new team members get up to speed quickly and greatly increases truck factor.

Maintainability

Good architectures tend to be built around good programming patterns and practices. As such the fragility and therefore maintainability of an application is improved. Maintainability relates to the time to locate, time to implement and impact of making a change to an existing code base. A good architecture will make it easy to locate where to make a code change due to the factors discussed about consistency. It will offer a structured approach to implementing such a change and therefore reduce the time to do so. The effects of this change should have little or no impact on the rest of the system as a good architecture will be open to and accommodate change. Coming back to an old long-forgotten project will be much easier to re-familiarise with if it was built using a common architecture as opposed to having to pick through reams of unfamiliar forgotten code with no particular structure.

Flexibility

A key consideration when planning an architecture should be flexibility, offering an easy approach to changing or adding to an implementation without resorting to complete re-writes. As mentioned above good architectures are open to change and should enable developers to embrace changes to specification rather than having to constantly refer to the initial fixed requirements and resorting to lengthy, over-complex change control processes. When the inevitable happens and the clients want to switch back to the original implementation this will be no problem as opposed to addressing the situation by throwing your computer out of the window.

Code Re-use

A much touted tenet of object oriented programming is code-reuse. Whilst in reality code-reuse should not be as much of a priority as perhaps some of the areas mentioned above, it is still a bonus for well organised and well architected code. Logically organising functionality into related groups with fewer dependencies on the system being developed will offer re-usable libraries to other projects and also offer the ability to integrate other existing open-source and commercial libraries.

A lot of the points discussed above are nothing new to seasoned developers but I wanted to get across a viewpoint that could perhaps be more digestible to clients and managers who need to be sold on the business benefits of time spent on aplication architecture. Often it can be difficult to see the immediate benefit when the short-term objectives can perhaps be achieved quicker but unknowingly at the expense of the longer overall goal of quality, effective software and to the overall detriment of deadlines.

I have also tried to focus the discussion on "architecture" as a generic term for good development practice and not specifically on frameworks, a good architecture absolutely does not need to involve any of the common frameworks available. That said understanding and using an existing framework is a good way to save time re-inventing the wheel.

Read more from Dan Thomas.