Knowledge-Sharing Architects As An Alternative to Coding Architects

 
Author:  Follow: TwitterFacebook
Job Title:Sarcastic Architect
Hobbies:Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek
 
 
Architect in a Straightjacket

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).

Inquisitive hare:Let’s start with considering the arguments which are commonly presented in this debate.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 think that it can be only avoided by the architect coding (ways to deal with it without specifically coding will be discussed below).

[[To make it very clear: I am NOT arguing with [Coplien05] here; I am arguing with the point of view – the one that architects MUST code – which is quite popular among certain developer teams, and proponents of which refer to [Coplien05] pretty often]]

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.

Hare pointing out:Moreover, it does imply that architect should be able to write code (however, there is a substantial difference between 'being able to write' and 'doing it every day').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 (however, there is a substantial difference between “being able to write” and “doing it every day“).

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 any of the last two observation 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.

Arguing hare:Working only on one part of the whole large project reduces opportunities to see the Big Picture.Not seeing the forest for the trees. A biggie. Working only 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 subproject. 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.

Assertive hare: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.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.

Assertive hare: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™).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.

Hare wondering if you are crazy:If you’re an architect and are thinking along these lines – you’re horribly out of place.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.

Coding architect

Hare thumb down:knowledge sharing won’t happen, pretty strong dependency on the architect will still exist, 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.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.

Hare asking question:“how do knowledge-sharing architects maintain that level of brilliance in coding once they don’t code anymore?”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

Judging hare: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.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.

Surprised hare: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.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

Thinking hare:I’ve seen teams with knowledge-sharing architects scale better, and deliver higher quality code, than those teams with merely coding architects.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.

Don't like this post? Comment↯ below. You do?! Please share: ...on LinkedIn...on Reddit...on Twitter...on Facebook

[+]References

Acknowledgements

This article has been originally published in Overload Journal #132 in April 2016 and is also available separately on ACCU web site. Re-posted here with a kind permission of Overload. The article has been re-formatted to fit your screen.

Cartoons by Sergey GordeevIRL from Gordeev Animation Graphics, Prague.

Join our mailing list:

Comments

  1. Wanderer says

    Mostly in line with my experience.

    And, yes, working under command of “heavy-coding” architect can be a real pain and, based on my experience, it can actually negate the respect and the desire to work. When most of the project decisions, even small ones, are made by architect, it kills the sense of importance within developers. Who wants to do better if architect just uses them as “dumb harvesting units” in his mind game. Since I got my hands on the book “Herding Cats: A Primer for Programmers Who Lead Programmers”, I use it quite often as an example for a really great advises on how to manage the team. And, it is rehearsed across the book that delegating is a key for lead developer (which is a prime candidate to evolve into architect soon).

    Also, “cherry-picking” attitude can be hard to resist. Personally, I found way to workaround it a bit and it’s to use a “prototyping” approach from time to time. We all know that 100 lines of code can say more than hour-long discussion and a bunch of UML diagrams. So, thinking about non-trivial cases and “making architectural decisions” can actually be done in form of coding. My experience says that it’s better when this is performed out-of-main-code, although it’s not always possible. Applying this approach reasonably can satisfy architect’s thirst for self-coding, while keeping the hands outside of develop branch 🙂 As always, the key is to keep the amount of this reasonable and not over-do it.

    • "No Bugs" Hare says

      > Who wants to do better if architect just uses them as “dumb harvesting units” in his mind game.

      Of course, that’s not the point. What is the point, however, is that there are things (like “we want to add this API between these modules” or even worse – “hey, we want to use this ingenious 3rd-party library”) which DO need to go via architect (doesn’t matter too much whether it is one person or not). Otherwise, the code tends to degrade into a mess way too quickly.

      > it is rehearsed across the book that delegating is a key for lead developer

      Exactly! However, delegating while you’re coding yourself, is inherently more difficult than when you don’t code :-).

      > it’s better when this is performed out-of-main-code, although it’s not always possible.

      Good idea, I’ve done it myself, but wasn’t really able to articulate it by the time of this writing…

  2. says

    I’m not commenting because I don’t like this post 😉 First, in quoting me about the need for architects to code, you’ve carefully carved out a straw man on false grounds. Then, once having set up the straw man, your subsequent arguments are unbalanced with respect to how you abuse a single citation out of context. If you look at my broader publications and talks, I am definitely as much of the knowledge sharing school. And I don’t choose to feign ignorance about any single facet of knowledge within the scope of architecture.

    First, knowledge is broader than application domain knowledge, and I fear this post tends to equate those two. A great architect masters both conceptualisation of social and client needs and of the tools of the trade — the mortar, brick, and sweat that in our discipline is called “coding.” Too many contemporary architects are just philosophers (maybe you are trying to give them some dignity by saying that they share knowledge) with nice tidy intellectual packages that lack engineering and implementation plausability. This tension has long been recognised in architecture, all the way back to some of the earliest architectural literature. Vitruvius says:

    “. . . [A]rchitects who have aimed at acquiring manual skill without scholarship have never been able to reach a position of authority to correspond to their pains, while those who relied only upon theories and scholarship were obviously hunting the shadow, not the substance. But those who have a thor- ough knowledge of both, like men armed at all points, have the sooner attained their object and carried authority with them.”

    You seem to want it one way or the other. That’s a natural step at one stage of maturity in architectural thinking. Several levels higher, and you can transcend this dichotomy — as building architects have for centuries, and as the great software architects of today also do, and as Vitruvius led the way.

    As for my own position, much of my research (and subsequent practice) has been based on characterising the application domain in terms of commonality and variability analysis along the lines of common cognitive structures. Much of the ceremony around this activity centres on the sharing of the knowledge from domain experts and the team. Indeed, the formalisations I’ve pioneered were created primarily as an informal knowledge-sharing tool. I have always underscored the importance of grey-haired domain knowledge. It’s one of the reasons we founded the software pattern discipline back in the 1990s — same song, different verse.

    Scrum is much about sharing knowledge across all stakeholders. Nonaka-sensei, heralded as the “Godfather of Scrum” by Jeff Sutherland — someone who has dedicated his career to knowledge management — personally notes that the contributions I made in patterns were an important stage in his understanding of Scrum development.

    The most common theme in my most recent book, co-authored with Gertrud Bjørnvig, is: “Everybody, all together, from the beginning.” Sharing.

    So I agree with your vague, broader, point, but shame on you for doing sloppy homework. I think you have more reading to do — out of the shadows, and into the substance. And then you can start to think, and go beyond thinking to the feeling that is truly at the heart of great architecture.

    • "No Bugs" Hare says

      > First, in quoting me about the need for architects to code, you’ve carefully carved out a straw man on false grounds.

      TBH, I didn’t intend to present that-thing-which-I-am-arguing-against as your point of view (and didn’t intend to argue with you personally either). From my point of view it is Very Simple: there is a Damn Misperception out there (the one that architects MUST code), which I am trying to refute, and I don’t really care what do you personally think about it (neither I claim to know it BTW); yes, I’ve quoted you but I’ve explicitly(!) agreed with the quote, and the observation that it was your work which has “probably started” this Damn Misperception – well, given the frequency with which it is quoted in discussions on the matter – I think it is rather justified. I don’t think that I’ve attributed anything else to you (except for pair programming, which I’ve also agreed with), and I didn’t mean to say that you think or say something specific about it (I am NOT a mindreader). Still, as you seem to have problems with my wording – my apologies, I did NOT intend to misrepresent this Damn Misperception as your point of view.

      If it is “However, I don’t agree that it can be only avoided…” part which worries you (and which indeed can be understood that it is your point of view, which I didn’t intend) – let me know, I will change it to “However, I don’t think that it can be only avoided…”, so there won’t be a chance for misattribution.

      Side note: Overall, I’m not interested in arguing with people – but only interested in arguing with statements (especially with “common wisdoms” and “profound truths”), whoever the author is. You’re not the author of the stuff I’m attacking – good for you, I have no problems with it :-).

      > I fear this post tends to equate those two.

      No, it doesn’t (moreover, IMO it should be Very Clear from the article itself – even the single phrase “architect who is one of the best coders around” in the context of the thing which I’m pushing, should be sufficient to see that I don’t). Also I want to note that it is quite strange to read this kind of misattribution just 10 lines below a complaint about straw man arguments…

      > You seem to want it one way or the other.

      Wrong again. BTW, you seem to lead 2:1 by (perceived) straw man arguments (and we seem to have a 1:1 draw by sloppy homework too).

      > I think you have more reading to do — out of the shadows, and into the substance.

      I’m afraid that you’re wrong again. I have more WRITING to do (for 12 long years between 1998 and about 2010 I neglected to write, so now I’m catching up). In particular, I am planning to write about Scrum (and how it is effectively killing agile these days 🙁 ). It may take some time (these things are not my primary focus), so – stay tuned!

  3. FennNaten says

    Nice writeup!
    I mostly agree with your points here.
    I guess I would add that:
    – as architects, beside the project at hand and technicalities, also have business facing time, cross-company tasks, trainings to give, and the like, having them code features, especially if critical, is calling for failure. They’ll happily start, then won’t have time to complete because of excessive context switches, and ultimately they risk making everybody late because they underestimated the amount of interruptions coming with responsibilities.
    – as an addition to the ones you present, I think maybe one additional case when it’s okay to code as an architect is when you need to earn some credit with the rest of the team. Take on something a bit hard, short, uninteresting, document better than the level of documentation you require, code well and have them review your code. A way to lead by example.

    • "No Bugs" Hare says

      > They’ll happily start, then won’t have time to complete because of excessive context switches, and ultimately they risk making everybody late because they underestimated the amount of interruptions coming with responsibilities.

      Exactly 🙁

      > I think maybe one additional case when it’s okay to code as an architect is when you need to earn some credit with the rest of the team. Take on something a bit hard, short, uninteresting, document better than the level of documentation you require, code well and have them review your code. A way to lead by example.

      Yes, you’re right – especially if you’re coming into existing project with an existing team (and the team being Good). I guess I missed this one because I’m usually working on the projects which start “from scratch” ;-).

  4. says

    I’d like to add that a knowledge sharing architect can efficiently postpone design decisions, for example by doing research parallel to development. These experiments really help serendipity / find an even better solution.

Leave a Reply to "No Bugs" Hare Cancel reply

Your email address will not be published. Required fields are marked *