Software architect role in agile projects

Discussing the role of software architect we need to consider the following:

In the agile development we are moving away from the waterfall method. This means that we have no way to build the full architecture of the system in the beginning phase since we have no basis for this, no specification to follow, no full description of features that will be implemented and no time to be spent on this task.

In the result we are urning around the process of building the architecture - from the concept in the beginning to the periodic refactoring after x iterations and the constant control of what is happening in the system, monitoring of problems developers are dealing with due undecided or new gaps in the architecture.

All this (but in the more structure way) is described in this article, and presented  here.

TDD is great for some project, but in many it gives just a false feeling that errors are under control

Comments following "Agile Ruined My Life" post

TDD is great, for SOME things. In other cases it can just add hassle and has the danger of providing a false sense of security. If I come across a project that does nothing but TDD and sees that as the only validation of their work that is necessary (this happens very often) I can pretty much guarantee I can find higher level functional, flow and integration cases that break the carefully constructed classes.

TDD is good for braindead simple crap programming where you have a well defined set of requirements and need to slog through them. I used it today when I needed to write about 30 java classes to fill in the functionality of an app I had built. That allowed me to both ensure that I had all the details working and test the framework itself and ensure it did everything I intended it to do correctly.

Now the core of the app itself involved juggling about 50 complex files at the speed of vim with multiple teardowns and rewrites over the course of a few days. Lots of experimentation and learning. Any tests that I would have written would have broken irreparably within minutes. It was a purely creative endeavor. You cannot do that with TDD and if you try you will spend weeks refactoring tests and not seeing the forest for the trees.
By far the best thing TDD has brought to the table is test frameworks though. Having a nice place to throw all your throwaway assertions on acid is awesome and really does add to the confidence level even if it affirms that you just broke an assumption you intended to break.



TDD - is a very popular technique nowadays. Unfortunately there is very little number of tools that are universal. Therefore it is necessary to clearly identify for yourself - where the tool should be used and can save a project from failure and where appliing the tool can be either pointless or even harmfull.