24 November 2011

Agile Architecture

There are two core principles to architecture in an agile environment which worked for me real good :

  • Document only small slices of the system one at a time at the time you need them
  • Be as specific as you need without going into too much details
A typical business system, one that is software intensive, is a really big and complex. When developing one such system it is impossible to document everything at once. What I do is to create a general corner stone architectural specification that defines the core architectural areas and principles of the system, a reference architecture around everything will be build and then create a series of small architecture documents (Architectural Notes or Memos) which are slices of architecture targeted at a specific system view or functionality which is developed for a first type. Architecture is a generalized specialization so such documents must convein all the information one needs to implement the designed architecture but not specialized too much in order prevent the multiple variants the same architectural areas can have. 
It is important not to design to early , but at just the right time. The goal is reduce the amount of time passed between the design creation and the implementation and to focus the architectural effort on the architecture which is need right at this moment of the currently developed sprint. 
Designing and documenting and architecture slice is one part of the whole problem, even when you create such a design at the right time with the right amount of detail the majority of the subsequent effort is spent communicating and reviewing the architectural implementation. If the implementation part is done by the architect and the senior team (such as the core of the system) a significant part of the architects effort is spent disemminating through the development team (or teams) the culture and the ideas required by the architecture design. 
Software is plastic, and programming is flexible. Event the most pure architecture can be twisted, scratched and mutated in something recognizable. The best way to insure an architecture to survive is to set up much of its essence in code and build tools which guide the developer down to a certain way of solving problems (which has its own problems , which is why architecture should be approached slice by slice and nothing is one hundred percent fixed in stone and unchangeable) and to integrate its core principles into the development culture of the development team which will ensure it gets adopted by every new team member.
Lots of teams make use of the shared tribal team identity as the only reference how things should be done by the project. This practice is spurned by software engineers, and with good reason, because software cannot be developed with tribal memory and shared culture alone, documentation must exists, tests and build tools must exists in order too enhance the human falabilities to which we all are susceptible : short memory, illness, death, holidays and leaving for a better opportunity. In its essence agile development values people over processes and interaction over rules, it doesn't mean no documentation or processes should be in place. We all are humans, and by definition fallible. Agile architecture should strive to reduce the human error by documenting and the essence of small specific slice of the system such as : grid architecture, background process architecture, form architecture, repository architecture, commenting system architecture etc.
Short is better for software developers, people will more eagerly read a ten page document then a one hundred page document. They will read it more often and learn more from it. It is also really easy to communicate a short document then a large one. Also, less errors are introduced in a short design then in a large one.
The agile manifesto reads as follows:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

The agile manifesto clearly indicates that things on the left are more valuable then things on the right, but things on the right have a value. They are second to the things on the left, people have more value to software development over processes and tools, working software is king over documentation. But a balance must be made, without a documentation who will understand what is being developed? Without a set of class diagrams that show the core architecture for a subsystem from top to down and text describing it who will understand the code without someone guiding him through? 
Each day when I start my work I say to my self :

Your job is to enable other people to do their job better

I'm a technician and my focus is technology and the development team that works with it. I'm a software engineer by trade and a craftsman by soul and I really think only three things are important in software development:
working software, people and communication

For me agile architecture is that which maximizes those three things.

23 November 2011

13th IT PRO Meetup: Agile Architecture

On Monday 29th 2011 at 19.00 o'clock I will hold a talk for the IT PRO User group on the topic of Agile Architecture. This is something I'm  very hot for right now since I get to practice it for the last six months on a very large project with a geographically distributed team.
I will focus on my experiences and what worked best and what didn't in order to present a practical take on the topic.
You can register for the event here , there are only twenty free slots for the talk so please hurry if you want to hear me speak.

09 November 2011

ARM Assembly Language

I've started reading a great book about the ARM assembly programming language. The book can be found on-line here and is a web copy of the same book published in 1987.
Why I'm reading this twenty year old book for an assembly no sane .NET or PHP developer heard about (sure someone did, but the meat and bone of the developer population I mingle in cerentanly didn't hear about it)? The reason is really simple.
I need to learn ARM assembly programming so I can understand the code written in my Operating Systems handbook of the undergraduate Computer Science course I enrolled this year. The book is full with ARM assembly examples how different parts of a system function and I really need to know ARM syntax to fully understand the problem space. The book is of course the venerable "Operacijski sustavi" handbook from FER (2011 edition).
It is not a bed book, but its thick with text which sometimes isn't written well (I'm a published fiction author translated in four languages and published on three continents so I know when something isn't written well, mark me) and requires two readings to understand the rich and very complex sentence structure which could be written more simply if the author actually cared about the reader.