Title: Knowledge-Sharing Architects As An Alternative to Coding Architects

Author: Martin Moene

Date: 08 April 2016 21:29:51 +01:00 or Fri, 08 April 2016 21:29:51 +01:00

Summary: Should architects write code? Sergy Ignatchenko explores this controversial subject.

Body: 

In recent years, quite a few articles have appeared with pro and contra arguments (mostly pro ones) on the question of whether software architects should code. Just to give a few examples, [Bryson15], [ArchitectsDontCode], and [Mirakhorli16] all argue for architects coding. There are a few articles out there such as [Langsworth12] which are trying to discuss both sides of this choice, but they seem to be overwhelmed by what was probably started by [Coplien05] and is rapidly becoming a ‘common wisdom’ of ‘Architects Should Code’. Moreover, the ‘Architects Should Code’ point of view is supported by lots of developers out there, often by those who suffered from the hands of idiotic architects (who are unfortunately as abundant as not-so-good developers).

We will take a closer look at the arguments presented, double-check them against anecdotal evidence available (a.k.a. what I’ve seen and heard myself), and see where such analysis leads us. Let’s start with considering the arguments which are commonly presented in this debate.

Pro architect-coding arguments

Avoiding being ignorant of implementation details. In particular, [Coplien05] has said that:

...many software architects limit their thinking and direction to abstractions, and abstraction is a disciplined form of ignorance. Too many projects fail on ‘details’ of performance, subtleties of APIs, and interworking of components – or, at best, they discover such problems late.

I agree that this is a valid point. However, I don’t agree that it can be only avoided by the architect coding (ways to deal with it without specifically coding will be discussed below).

Responsibility. The most common argument in favour of architects coding is that architects should be responsible for the delivery of the project. I am not arguing with the ‘should be responsible’ part, but I don’t see that being responsible necessarily means coding. Yes, a good architect must work closely with the delivery team [Bryson15]. No, working closely with the delivery team doesn’t necessarily mean coding (which is consistent with [Langsworth12]).

Feedback. The second common line of pro-architect-coding arguments is that development is an inherently iterative process, so architecture should evolve as the product is being developed. I am not arguing with this point either, but I agree with [Langsworth12] that not writing code doesn’t necessarily mean lack of feedback.

Respect. For the project to be successful, the architect should be respected by the team. Once again, there is no argument against this point. Moreover, it does imply that architect should be able to write code.

Observation 1: “Developers have more difficulty [than architects] implementing architectural choices” [Mirakhorli16]. This observation is interesting because it has a solid science behind it (there was a scientific study, with statistical analysis etc.). And yes, my own experience does support this observation. Once again, there is nothing to argue about here.

Observation 2: “Non-architecture savvy developers introduce more defects into architecturally significant code snippets than architecture-savvy developers” [Mirakhorli16]. This one is also supported by solid science, and once again my own experience supports this observation as such. And no, I still don’t see why it means that the architect should code.

As you see, I do not argue with any of the points commonly presented as arguments for architects coding. On the other hand, I do not see why they necessarily mean architects should be coding on a day-by-day basis. Of course, I realize that ‘I don’t see why this or that point means coding’ is a very weak argument – that is, until I can articulate a development model which addresses all these issues without coding. Don’t worry – it will follow below.

Contra architect-coding arguments

Now we should consider the other side of the story, and see why architects coding might not be that good an idea. Note that we’re speaking about those architects who do work closely with code, but do not code themselves.

Not seeing the forest for the trees. A biggie. Working on one part of the whole large project reduces opportunities to see the Big Picture. This is especially risky if your project has the concept of ‘code ownership’, but even without it, an architect too busy with debugging a piece of code is less likely to ‘swap out’ of this task to see a substantial architectural problem in the adjacent project. Been there, seen that (and was guilty of it myself too).

Time is better spent on other parts of the same project. This one seems to be strongly underestimated, but it is just a fact of life. There are only 24 hours in a day, and it is much more efficient for a good architect to spend her time on the other code-related things, such as code reviews and sharing knowledge about the architecture of this specific project (as well as about programming practices in general) with team members. More on this below.

Context switches are expensive (and no, I’m not speaking about threads). By the very nature of the architect’s job, on the one hand he needs to be ‘readily available’ as soon as somebody needs architectural advice. The usual pattern goes as follows: somebody wants to add a function (class, whatever) to an infrastructure-level API, effectively exposing certain previously hidden implementation details. At this point, it is the architect’s job to say that it doesn’t belong here, and should be done on top of existing API in such and such manner (which happens 80% of the time), or to agree that such a function is indeed necessary (remaining 20%). This pattern happens all the time for all the teams around the world (from a kernel team to a big government development, with everything else in between). Even for a team of 5, this process leads to interruptions being quite frequent (and the larger the team, the more interruptions experienced). On the other hand, being involved in a significant development requires concentration for several days, and such interruptions cause ‘context switches’ from coding to architecture advice. These ‘context switches’ (just as for threads) tend to be extremely annoying and lead to suboptimal decisions both for coding and for architectural advice.

While DIY is easier in the short run, it doesn’t scale, and knowledge-sharing does scale in the long run. Another biggie. If the architect is a hands-on one but she doesn’t code, then to fix some architecture-related problem she’ll need to explain the problem (and how to solve it) to somebody else. And as soon as you’re explaining something, it means that the knowledge and, even more importantly, the ‘feeling’ about the architecture of your specific project is spread among developers. This is extremely beneficial in the long run (both according to Observation 2 above, and according to my own experience). Yes, for a good architect it is much easier and faster to code it herself. But after doing it herself, very little has changed in the minds of the other developers, so the next time she will need to code it herself again; and again; and again. It means that the development process doesn’t really scale well. On the other side, if she spends more time now to explain things, the next time there will be more understanding of this kind of task (in terms of Observation 2, there will be more architecture-savvy developers in the long run), so more and more tasks can be safely delegated (and will be done according to the proper architecture for this project, too). I see this point as a Really Big Argument for knowledge sharing practices.

Dependency on the Architect. As noted above, non-coding (but working closely with code) architects are pretty much forced to share their knowledge to have things running. As a nice side effect, the very same knowledge sharing weakens a dependency on the architect (and reducing any dependency on a specific person is a Universally Good Thing™). While not-so-good architects might go nuts after realizing this point, good ones don’t need to protect their jobs by being ‘the only person who knows how to change this damn thing’.

Contra architect-coding non-arguments

There are also several non-arguments which are often pushed to support non-coding architects.

Architecture should not be concerned with implementation details. A Really Bad non-argument. In my book, an architect’s job is to deliver a solution, plain and simple. Doing that means that the architect needs to be sure that more-or-less optimal implementations are possible for all the components of the architecture; moreover, the architect needs to suggest these implementations if the need arises.

Architecture is written once, then the architect can leave for another project. Note that this one is very different from the ‘Time is better spent on other parts of the same project’ point made above. Moving on to a different project, at least until current project enters the maintenance phase, is an almost-sure recipe for disaster.

Architect is a high-level role, is all about business lunches with customers, and developers even don’t know how to play golf. I don’t even want to discuss this one. If you’re an architect and are thinking along these lines – you’re horribly out of place.

Two things which work

Ok, we’ve stated all the arguments (and ignored non-arguments) from both sides. Now we need to architect a system which provides a reasonable balance of the answers.

Actually, there are at least two approaches which work. The first one is very simple – an architect who’s coding (yes, current ‘common wisdom’). It will work, at least as long as the architect is not too concerned about his own part of code and is not interrupted too often. However, knowledge sharing won’t happen, pretty strong dependency on the architect will still exist (which is a good thing for the architect, but not necessarily for the project), and lack of time for reviewing code may lead to code quality taking a slippery road towards being unmanageable. All these issues are admittedly non-fatal, but I know that we can do better than that.

The second approach is the one I am arguing for, and I prefer to name it the ‘knowledge-sharing architect’.

Knowledge-sharing architect

Here we’ll be speaking about an architect who is one of the best coders around, but is not normally coding herself.

Note that for a knowledge-sharing architect, ‘not normally coding’ does not mean ‘not involved with code’, but the exact opposite: ‘working with as much code as possible’. Such ‘working with code’ can and generally should involve most of the following:

• code reviews (formal ones and informal ongoing ones too)

  these often lead to showing ‘how to code it better’

• pair programming (which was in particular suggested by [Coplien05], though I don’t think that it is the only thing which can work in this regard)
• considering architecture-change (and often certain high-level API-change) requests from the team
  • these normally lead either to an explanation ‘how to do it’…
  • …or to changes to APIs, code guidelines, etc.
• and discussions with team members on possible solution for arising problems (which lead to guidelines updates etc.).

Let’s see how such a knowledge-sharing architect will deal with the pro and contra arguments listed above.

Both responsibility and feedback are right within the process, and respect among coders is not too difficult to achieve (after all, our architect is one of the best coders around). The impact of Observation 1 is not too bad (as there is a constant education, and enough time for code reviews). With regards to Observation 2, the long-terms effects of having a knowledge-sharing architect are much better than with the coding-architect approach due to, well, knowledge sharing.

One additional argument in this regard is: “how do knowledge-sharing architects maintain that level of brilliance in coding once they don’t code anymore?” The answer is simple: as knowledge-sharing architects (as described above) are working with more code rather than with less code, this will help them to keep their coding skills top-notch. In other words (and for one specific example): knowledge-sharing architects are giving up up-to-date training in the skill of ‘how to find that off-by-one error’ in exchange for the skill of understanding the code of the others (and learning new tricks from them too). There is no magic here, and to improve one skill, you need to give up another one, but I am arguing that the skill of understanding what’s going on is more important for an already good coder than day-to-day training in figuring out rather stupid bugs (and 90% of all the bugs are outright stupid, so dealing with them doesn’t benefit coding skills much).

Now let’s consider the arguments listed in the contra section. With a knowledge-sharing architect, ‘Not seeing the forest for the trees’ has much less chance to occur, and there is more time for working with code (so that much more code can be covered; this is also helped by not having those expensive context switches). Even more importantly, due to knowledge sharing the development process becomes more scalable, and dependency on the architect is reduced.

Side-by-side comparison

Let’s summarize the above findings in a table:

	Coding architect	Knowledge-sharing architect
Ignorance about implementation details	No	No
Responsibility	Yes	Yes
Feedback handling	Time permitting	Yes
Respect of team members	Yes	Yes
Observation 1: difficulty with implementing architectural choices	Better in the short run, but no knowledge sharing in the long run	Worse in the short run, but better in the long run
Observation 2: more defects from non-architecture-savvy developers	Better in the short run, but no knowledge sharing in the long run	Worse in the short run, but better in the long run
Not seeing the forest for the trees	Medium risk	Low risk
Time available to spend on architectural issues	Less time	More time
Expensive ‘context switches’	More	Less
Knowledge sharing	Worse	Better
Dependency on the architect	Stronger	Weaker

As you can easily see from the table above, I am a big fan of the ‘knowledge-sharing architect’ approach. And it has worked for me in quite a few projects too. Yes, a coding architect might work (and is indeed orders of magnitude better than an architect who has no clue about the code), but a knowledge-sharing architect will generally work better.

Exceptions

While the knowledge-sharing architect is not normally coding, there are a few exceptions to this rule-of-thumb.

The very beginning of the project

One Big Exception to the ‘architect not coding’ rule-of-thumb usually occurs at the very beginning of the project.

It is always a good idea for the architect to establish a framework which will be used for the project, and it is often a good idea for the architect to write a big chunk of such a framework (and the first implementation over it) himself.

At this point in the project, the team (at least the part which can meaningfully participate in development) is small, so knowledge-sharing is not that big issue; and as the team is small, lack of time is not a big issue either. It means that at these early stages, the advantages of the architect coding may easily outweigh the knowledge-sharing aspect.

However, it is a Really Good Idea to prepare for moving to the knowledge-sharing phase as soon as the framework that defines the architecture is written, and not to be ‘the only person who knows about this piece of code’ longer than is absolutely necessary.

Things which nobody else can do

The second exception occurs when (for the sake of your project, I really hope these occur really rarely) it happens that the architect is the only person who can implement a certain feature. (While in theory it shouldn’t happen, in reality it does.) As we stated, the ideal architect should be one of the best coders around, and the other good coders might not have sufficient understanding of the Big Picture – or the time – to implement this specific feature.

In such rare cases you simply won’t have an option other than for the architect to code this feature herself, and it won’t be the end of the world. Note, though, that this is different from the ‘architect coding only the difficult stuff’ approach (which was criticized in [Bryson15], and I do agree with that criticism): here we’re not speaking about cherry-picking the difficult (and interesting) stuff, but rather about doing it when there are simply no other options.

Conclusion

I hope that I have managed to convince you that a knowledge-sharing architect is better than a coding architect. The difference is subtle, but I’ve seen teams with knowledge-sharing architects scale better, and deliver higher quality code, than those teams with merely coding architects. While YMMV, and batteries not included, there are good reasons for these observations (which were outlined above).

However, there is one big practical problem with switching to the ‘knowledge-sharing architect’ development model. The problem is that most good architects won’t be willing to give up coding (often ‘cherry-picking’ the most interesting pieces, but that’s beyond the scope now), so the question of how to convince them to start knowledge-sharing isn’t likely to be trivial.

On the other hand, as soon as it is understood that knowledge-sharing architects are beneficial to the project as a whole, the architect naturally faces a dilemma: either to continue to code (in the understanding that this is not the best way to serve the project), or to start knowledge-sharing. While certainly not an easy choice, this might lead to a switch for your architect from coding to knowledge-sharing (and if it doesn’t, it is usually better not to push them too hard, as a persistently unhappy knowledge-sharing architect won’t be any better than a happy coding one).

In any case, there is no argument that having an architect who has no clue about the code and doesn’t bother himself with ‘implementation details’ is pretty much a guaranteed one-way ticket to a nothing-good-comes-out-of-it land.

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.

References

[Coplien05] https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/TopTenPatterns

[Bryson15] http://www.infoq.com/articles/architects-should-code-bryson

[Mirakhorli16] http://blog.ieeesoftware.org/2016/02/why-should-software-architects-write.html

[ArchitectsDontCode] http://c2.com/cgi/wiki?ArchitectsDontCode

[Langsworth12] http://randomactsofarchitecture.com/2012/11/20/should-software-architects-write-code/

[NoBugs15] ‘No Bugs’ Hare, ‘Non-Superfluous People: Architects’. Overload #127.

Notes: 

More fields may be available via dynamicdata ..