I’ve had this entry in draft mode for a while, and seeing as I am likely to have limited access to the Internet next week, it’s probably best that I get it out there. After all, I believe that all constructive feedback (both positive or negative) is useful.

The traditional software architect role is an interesting one. Developers, who choose not to go down the management line for one reason or another, typically take up this role. Defining what an “architect” does in a traditional software environment seems to be pretty well known. Trawling some job advertisements you see role descriptions like, “translate business requirements into a framework”, “high level analysis and design”, and “technological evangelization”. My observations of a real ‘architect’ at work is that they generally do spike-like work, develop a little (but usually not so little) framework here or there, or suggest implementation patterns in the form of a tutorial or cookbook.

As a mad keen developer, who is into Test Driven Development (TDD), constant refactoring, and evasion of Big Design Up Front (BDUF), I question where does this role fit into newer software development processes? I respect these people, because they have been around for much longer than I have. They probably have a wider repository of patterns to drawn upon and the wisdom of learning from many different projects. I question this, because I think the typical responsibilities fail in an environment that I like to work it.

Architects in their traditional sense, typically fail because they work leagues ahead of the development team. Sometimes they run with BDUF, but other times, they do spike work that sets a pattern for a simple use case, but fails to address the needs of many other ones. Since they rarely look back at the things they have done, architects rarely get any feedback, and one of the most useful of eating your own dog food. It sometimes gets to the point where the architect starts dictating architecture with diagrams instead of actual code, failing to see the difficulties of how untestable or how inflexible it might be when actually implemented!

Here is my revised list of descriptions on the software architect role in a modern software development team:

• The architect should be an embedded member of the development team – Like it is important to have a customer representative and a tester during an iteration, the architect must be someone a team member can go to for direction relating to a technical feature when unsure. Although it is okay for architects to work on technical spikes in advance, they should also be looking at the implemented result under all real circumstances.
• Identifying, extracting and naming patterns out of the system – Refactoring code is excellent at a microscopic developer level as you can draw out a better, more maintainable piece of code. Refactoring during an iteration by developers working on stories tend to have too much of a narrow focus to influence a large entrenched system. Excellent test coverage and well-written tests also give the architect an ability to execute on this, without having to leave the code in the state that it is.
• System-wide Odor Purification – Bad smells reside in code all over the place for one reason or another. Identifying bad smells throughout a system, highlighting them, developing a strategy for getting rid of them, or better yet, actually removing them is important. Once again, developers do this on a microscopic level but similar smells may co-exist in several parts of the system.
• Mediating technical discussion – Although BDUF is never useful, it is sometimes to useful for a team to talk about different problem solving strategies (a general approach) to take. Reality will always step in and cause something to deviate from a ‘plan’, and the architect should support brainstorming activities and should be able to step in and prevent discussions that become ineffective, and do turn into BDUF.

Somehow I always seem to end up coding the user stories that have the most demanding time constraints. In a way, I feel flattered that someone trusts my ability to deliver when a critical deadline must be met (and real deadlines are very rare in software, despite what everyone tells you), but it is always interesting to see how people react when a critical deadline must be met.

Over the numerous occasions that I have been working on these “time critical” stories, the common question you are normally asked is, “So when do you think we’re going to be done?” or better yet, “Is it ready yet?” As a developer I find it is better to preempt these sorts of questions by delivering feedback earlier than they expect. Typically this means walking through significant, visible progress with the stakeholder, or bringing visibility to issues that are hindering your ability to deliver (e.g. database environments not available, etc). Customers are typically trained to ask “Is it ready?” because they are given such little feedback. The customer should not be surprised when something will be delivered and it easy to forget this.

Another question that you tend to get asked is, “Can you get it done any faster?” Speed is essential to any business, but it is important to highlight what you sacrifice for speedy delivery. Translated into software terms, this may mean less regression tests to provide automated feedback of features breaking when future changes are made, duplicated code, leading to confusion, additional maintenance and even developer shame, or an undesirable path that meets requirements but leads to an unacceptably sluggish solution as load increases. When time is critical, ideally the business should be prioritising which things are more important, but usually it is left for developers (for better or worse).

Achieving your goals as fast as you possibly can is good, but keep in mind that developers are more like runners than they are computers and do get “tired” (for want of a better term). If you want to run a marathon, you certainly don’t run at the same speed as you would the 100m. Instead of asking how fast you can run, the question that should be first asked is how far do you want to go?

Although I am not the iteration manager for our project, I like try to be our project’s conscience (or at least the conscience of whoever our current iteration manager is). Amongst the (many) things I have been reminding our current iteration manager of is the lack of retrospectives. One reason that agile software processes are better off than traditional long running ones is because feedback is a highly valued principle. Small iterations improve the regularity of this feedback which can then be fed back into the process to help the team stay agile with constant changes in the work environment. Retrospectives (post mortems, iteration reviews, etc) are a great way for the team to put together their views and devise strategies for processes that could be improved for the next iteration. The value of small iterations can diminish greatly if no one spends any reflection time to work out whether not things could be done better (and most things can always be done better).

Sailing is a great visual analogy that highlights the importance of retrospectives. On any sailing voyage it generally takes a while to get to its final destination. The navigator is the person whose responsibility is to keep the ship on course for its destination. They also understand the implications if the ship steers off course and is therefore constantly optimising the journey by considering all the questions that could affect the ship’s ability to get there. Are there enough supplies on board? Is there a storm lying ahead of us? Should we visit the exotic island that’s just a little within reach because our passengers would enjoy it? Even if the original journey is never altered, the navigator is constantly asking and reviewing the answers to these questions.

And just like in sailing, it only takes a little deviation over a long period of time to take a software team far from its original goal without someone (and preferably the team) stepping back and reflecting upon each significant league in the journey. An hour now with the team assuring that you are on track is better than an iteration making up lost ground. Performing reflective exercises more regularly will also improve the quality of the feedback as the team works out what sort of feedback is actually important.