For close to a year and a half now, I’ve had the opportunity to be in an architect role. This in itself has been something I’ve been looking forward to for quite a few years now, and I’m very grateful to the people that helped me maneuver into this position. The change to this role went gradually and for quite a while I was still involved in the development effort. This situation has given me a means to reflect on my time as a software developer, and making a case that I don’t want to go back.

There are some aspects that I’m aware of that contribute to this. The most important facet is that I’ve become very aware of my attitude at the job. During any (read: all) meetings or even casual conversations at the coffee machine, I’d be capable of snarling at anybody that had even a simple question to how much effort something should take. I see the same attitude from my colleagues. Any meeting that would suggest they would do any work, would result in venting, frustration and an overall bad attitude. The larger misconception here is that a question of “how much would this cost?”, is a very different question from, “can you have this done by a specific time?”

When any kind of management asks “can we do this?”, there is a fluidity to their question. Developers usually don’t appreciate this fluidity; they prefer certainties. What you ask of a developer forces them into making a promise, which they won’t do if they feel this cannot be done. When usually a question of “can we do this?” is in fact “what needs to happen so that we can do this?”

Organizations have various drivers and constraints, there is the classic triple constraint, resources, time and scope. We can break down scope in to quality and features. Having worked in organizations that care more about features than quality (though none would ever admit this), I find that developers respond equally sceptical.

The second point of contention is quality. (Project) Management usually perceives that a lot can be gained by sacrificing a bit of quality. So they will try to negotiate what quality we ‘can live with’ as to ‘what we want’. The fallacy lies in the fact that if you sacrifice quality at a certain point, this compromise in quality will have to be compensated for at a later point. If you save a week now, you will need to invest, likely more than, this week again later.

One of the main advantages of the organisation I work for now is that we’re aiming to maintain a high quality. The managers responsible for this version will be those responsible the next version. The developers working on this version will work on the next version as well. The organization and people part of that organization invest in a long term stable perspective. This means that a reliable quality is paramount. We’re not just selling our product, but as a team, we’re selling the perspective of being able to deliver reliably over a longer period.

Here’s where the role of an architect becomes very important. It’s the architect whomakes sure consistency and quality remain, while reliably adding new features. Though it might seem to require a glass ball to look into the future, inferences about the next step can be made with quite some confidence. Asking developers the right questions - ‘what do we need to build on?’ - and telling both management and developers on what is to come, is the right approach to ensure consistent quality and an effective use of the time and resources at hand.

I won’t pretend that, as an architect, I now oversee the world clearly and know exactly what to do; though I did gain a new perspective on how these relationships appear to work. This puts me in a better position to help my colleagues (developers and project management) establish a better relationship and bridge the mutual frustrations.