United Thoughts of a Distributed Mind

When thinking about my last post today, I was not quite satisfied with it. The values seamed quite unfocused to me in hindsight.

Actually I think we need to condense - especially the values - some more, so that we get at the essence of the agile spirit we need to be able to measure a good architecture against it.

In the end I think it boils down to the following three axes, along which an architecture (maybe embodied by a framework) can be judged (see the figure below).

I would contend, that an architecture satisfying all three of the axes is THE agile architectural basis for software development that is able to deliver on the agile promise.

Let us have a deeper look at the individual axes:

Change-Encouraging

This axis focuses on embracing change. For an architecture to support this, it needs to be easily modifiable, extendable, refactorable. If it is hard to change, it will lead - over the long run - to clumsy code, horrible work-arounds, lots of glue code and very extensive documentation, that needs to explain all of its quirks and potholes.

If it is easy to change and the developer is free to change his application at will, without too much effort, without breaking existing functionality of his application, then the overall design of the architecture (and the framework eventually embodying it), will remain simple, clean and easy to grasp over quite a long period of time (good tending practice implied).

Quality-Enforcing

Agility has one of its foundations in the delivery of production quality code on from iteration 1 to whatever number of iterations a project takes to complete. As such an application developed in agile manner needs a foundation, that has quality build right into it. This kind of architecture makes it hard for the average developer to make stupid mistakes.

It simple does not allow to circumvent good coding practices. It allows freedom of interpretation only in dimensions, that are in the application domain. It helps the developer to test his code in an easy, dare I say fun fashion, so that he wonders, how he could ever live without the safety net he is constantly weaving.

Value-Producing

Though I mention this axis at the end of this text, it is the focal point of agile software development. When we do not produce the right thing, it is of no use to produce it as fast as possible with the highest possible quality.

That said, it is crucial to produce value for the customer. The architecture should not stand in the developer’s way to produce some useful application. It should encourage him to produce value out of the box, to be able to show his customer a thin, but fully working, slice of the final product he will get.

At the same time it should prove to be a tool in the developers hands, that allows to try out easily alternatives, that can be quickly transformed into a visible artifact to put in the hands of the customer, so that fast feedback can be harvested, which eventually flows back into the development cycle.

Complementary products like acceptance testing support and generic self-documentation should help to produce value faster.

Conclusion

To produce an architecture (embodied in a application framework) that supports these essential values, may not be easy, but at least this is a starting point to think more deeply about principles that support this value-system.

As a nice side-effect I now have a system, that allows me to have a look at existing application development framework and weight them against each other. But I will spare this for another post.