Non-Superfluous People: Architects

No developer is an island. Sergey Ignatchenko continues his series of non-superfluous people by looking at the role of architects.

Disclaimer: as usual, the opinions within this article are those of ‘No Bugs’ Hare, and do not necessarily coincide with the opinions of the translators and Overload editors; also, please keep in mind that translation difficulties from Lapine (like those described in [ Loganberry04 ]) might have prevented an exact translation. In addition, the translator and Overload expressly disclaim all responsibility from any action or inaction resulting from reading this article.

The superfluous man (Russian: лишний человек, lishniy chelovek) is an 1840s and 1850s Russian literary concept derived from the Byronic hero. It refers to an individual, perhaps talented and capable, who does not fit into social norms. ~ Wikipedia

This article continues a mini-series on the people who’re often seen as ‘superfluous’ either by management or by developers (and often by both); this includes, but is not limited to, such people as testers, UX (User eXperience) specialists, and BA (Business Analysts). However, in practice, these people are very useful – that is, if you can find a good person for the job (which admittedly can be difficult). The first article in the mini-series was about testers; the second article was about User eXperience specialists. This third article takes an unexpected twist – and talks about architects.

WTF – Is there ANYBODY out there thinking that architects are superfluous?

Honestly, I didn’t plan to argue about architects in the Non-Superfluous People mini-series. For me, it goes without saying that you do need an architect, and I assumed that everybody else shares this understanding. After all, I am an architect myself ☺. However, Mother Nature has once again demonstrated that assumption is indeed the mother of all mess-ups.

A few weeks ago, I wrote a blog post presenting my understanding of the qualities which are necessary to become a software architect [ NoBugs15 ]. Actually, it was more about psychological obstacles which senior developers face when they need to become one, but that’s not the point. The post was discussed on Reddit [ Reddit ]. To my surprise, the very first comment was about Software Architects being ‘superfluous’; moreover, the comment was upvoted. This was the point when I realized that there are indeed people out there who think that architects are superfluous, and decided to include Architects to the series on Non-Superfluous People.

Software architects in successful projects

Actually, if you take a look at successful projects, you'll notice that each and every of them has an architect. This might be an official title, or it might be a de-facto architect, or it can even be a collective architect (i.e. several people performing this function) – but it exists. If we take a look at widely-known open source projects, we’ll see that each and every of them has an architect. In some cases (like with Linux or Python) the architect is very obvious, in some other cases (such as the httpd Apache [ daemon ] project, where the architect is a de-facto collective architect) it is a bit more complicated, but in any case there is somebody or some body (pun intended) making decisions about project architecture, and the rest of the people in the project comply with these decisions. There are two common reasons why non-architects comply with architects’ decisions. The first one is because architects manage to convince non-architects that their decisions are right; this is an ideal situation (and from my experience, it is possible to achieve it for 90–95% of decisions). While it takes time on the architect’s side, it both avoids confusion due to miscommunication, and keeps the team spirit. The second reason to comply is because of a formal ‘chain of command’; while it is significantly worse than complying due to the first scenario above, the difference between these two scenarios is really minor compared to the difference between complying and not complying. The range of scenarios can be represented as a table:

Approach	Results
Complying with Architects’ decisions because of being convinced	The best
Complying with Architects’ decisions because of formal ‘Chain of Command’	A bit worse, but still workable
Not Complying with Architects’ decisions	Disastrous
Not having an Architect	Very unlikely (see below), but disastrous

Can you really avoid having a de-facto architect?

Let’s take a bit closer look at the project mechanics. If your project already has a formal ‘Chain of Command’, most likely you do have a formal architect (whether she’s good or bad is a different story). If your project is an Open Source project which was started by one developer and the others joined when version 1.0 was already out, you have at least a de-facto architect. But what happens if you’re in an Open Source project with 5+ people working together who started more or less at the same time? Almost universally, it is the same pattern – at some point (for the project’s sake, it should happen sooner rather than later) the most influential developers come together and try to come to an agreement about the most important (whatever that means) issues for the project. If they aren’t able to reach agreement, the project is pretty much dead. At the very best, you have two fork projects wasting resources and causing confusion, which is usually disastrous at these early stages of a project. If they are able to agree – Bingo! At this point you’ve got a collective de-facto architect.

In fact, in my whole life I’ve never seen a project without some kind of architect. While I won’t claim that this observation is 100% universal, 99% is also quite a good number for our purposes.

If you are bound to have an architect, then why I am arguing for having one?

Those experienced with formal logic, may say:

“ You’ve just argued that every software project is pretty much bound to have some kind of the architect ”
“ Then, what’s the point of arguing that we should have one? As you have already said – we’ll get one pretty much regardless of what we’re doing ”

This logic is perfectly correct. However, I’m not arguing that you should have an architect (as noted above, it will happen regardless). My real point is a bit different – while you will have an architect pretty much no matter what, you SHOULD comply with her decisions.

Whatever you say, Dude!

Therefore, the real question is not whether you have an architect (you will), but whether you comply with the architect’s decisions. In most cases, this is not a problem. However, the chances are that you have at least one member of your team (let’s call him a ‘rebel’) who doesn’t think that discipline is a good thing, or just doesn’t have any respect for the architect guy. The reasons for rebellious behavior vary, and are not necessarily selfish; in particular, two common reasons for rebellion are ‘I would do it much better’ (and it doesn’t matter if it is really the case) and ‘What you have said just makes my life more difficult’.

However, the reasons behind rebellion are not as important as the strategy which the ‘rebel’ pursues. The first category of ‘rebels’ which I’ve seen is ‘open rebels’. They’re usually very loud and outspoken. The impact of such an open rebellion is usually not too bad, and necessary solutions (assuming that both architect and ‘rebel’ are guided by interests of the project, and are ready to listen to the arguments) can usually be found without ruining the project.

Rebels from the second category, ‘underground rebels’, are much more dangerous. If the ‘rebel’ doesn’t openly challenge the architect’s decisions, but instead doesn’t comply with them – then you may have a real problem.

Coming from theorizing back to Earth, consider just one rather typical example. There is a decision that all the code should be cross-platform. It is understood that writing cross-platform code takes additional time, but it is considered to be worth the trouble. However, one of the team members strongly disagrees with it. From now on, he may either raise an open rebellion, questioning “ Who was the Smart Guy who decided to spend time on this nonsense? ”, or may start pushing non-cross-platform code quietly. In the case of open rebellion, at least the team knows that there is a disagreement, and has the option to discuss it (hopefully coming to some resolution).

In the case of ‘underground rebellion’ which is not noticed soon enough, the things tend to be much worse. First, you as a team may end up with code which is not cross-platform (while you were 100% sure it is). Second, this tendency may be worsened by the fact that other (non-rebel and non-architect) team members may start using the existing code as a reference of ‘how to do things’ (or just copy-paste), which tends to proliferate non-cross-platform code across the whole code base. While it is newer team members who’re the most susceptible to this copy-paste effect, even architects, when their mind is on the other things, were observed to copy-paste code which is against their own decisions/guidelines.

What to specify?

Ok, we’ve established that it is important to have a consistent vision for the project, and to comply with it. But what should be included in this vision? In other words – what must be common across the whole project, and what can be left to case-by-case decisions by individual developers? While there is no one single answer on what to include in guidelines, there are some observations:

all deviations from common-practices-out-there MUST be explicit
all prohibitions on which-parts-of-the-language-we-dont-use MUST be explicit. For example, if there is a decision not to use C++ iostream in the project (IMHO a wise decision for a pretty much any project out there, but this is outside the scope now), it MUST be explicitly written somewhere
all not-so-common requirements (i.e. requirements which might be present, or might not be present in other projects of similar scope) MUST be explicitly stated. For example, if the code is intended to be cross-platform, it MUST be explicitly stated
things such as naming conventions are usually useful (i.e. time spent on following them is worth the trouble)
conventions ‘how exactly to place curly brackets’ (for Python an equivalent is ‘how many spaces to use’) are usually no

On job titles

Ok, ok, but what about job titles? Is it important whether an architect is called an architect or not? From my experience, the answer is ‘it doesn’t matter’. The whole thing is not about titles, it is about getting the job done.

On non-coding architects

Pretty often it happens that an architect starts as one of the coders, but then code reviews, processing pull requests, writing specs, discussions of issues with rebels, answering ‘how we should do this?’ questions etc. etc. start to eat too much time, and the architect starts to write less and less code. Whether it is normal or is a Bad Thing is an open question. From my personal experience, it is more or less bound to happen, at least if you’re a sole architect; however, it is always a good idea from time to time to take a limited-size-but-internally-very-complicated project and code it yourself (both because nobody else will be able to do it and to show the others that you still can code at least on par with the very best of them).

On enterprise architects

It should be noted that for the purposes of this article, we didn’t make any distinction between Project Architects and Enterprise Architects. However, while we’ve discussed things mostly from the point of view of the Project Architect, the very same logic will apply if we consider the whole Enterprise as a larger project (which is not strictly correct in general, but won’t affect our reasoning above). In short: you need both Project Architects and Enterprise Architects – all for the reasons described above.

Conclusions

You will have an architect (formal, informal, collective...) pretty much no matter what you’re doing.
What is important is to comply with architect’s decisions.
If you disagree with architect’s decisions, challenge them openly!
If you’re an architect, it is a part of your job to make sure that your decisions are complied with. BTW, recent project management tendencies (such as moving towards github with its ‘pull requests’ compared to giving direct access to the repository) seem to provide better support for ensuring compliance.
What to include into decisions/vision/guidelines is subjective, and there is a balance between specifying too much and specifying too little; some observations in this regard are listed above.
Issues such as ‘what job title should an architect have’ and ‘whether the architect still codes’ are pretty much immaterial.