
Knowledge-Sharing Architects as an Alternative to Coding Architects - signa11
http://ithare.com/knowledge-sharing-architects-as-an-alternative-to-coding-architects/
======
structorg
Let's start by defining architect. Where the business model is charging for
hours(consultancy) or bureaucracy is the rule; the architect is like a ming
dinasty china jar next in usefulness to the scrum master. He can't really
apply the principles of software quality since attributes like conceptual
integrity, reusability, modularity, loose coupling and maintainability are not
aligned with "picking the fad framework that average joe can be productive
with and charge the client for those 20 reports instead of a reporting engine
that can be parameterized, lets then use unit tests and code reviews to cheat
ourselves into believing we're making quality stuff". Its different when the
team is developing a product that is also the business model where resources
are never enough and there is no room for bullshit, then the architect is the
guy that can sketch that reporting engine that will be nurtured and improved
by the team, therefore he both codes and shares knowledge.

~~~
no-bugs
To be clear: I was NOT speaking of the first one :-). As for the second one:

> the architect is the guy that can sketch that reporting engine that will be
> nurtured and improved by the team,

Yes (in fact, I LOVE this definition ;-)).

> therefore he both codes and shares knowledge.

Not necessarily, and that's the whole point. Initial development (as noted in
the article) is one of the exceptions - but "sketching a thing that will be
improved" (which I agree with) is VERY different from "working day in and day
out on improving it" (which I do NOT like). And this difference is the whole
point of the article.

------
polskibus
Most of the concerns in the article can be alleviated by embracing Domain-
Driven Design. Express Domain Model in code, create and share Ubiquitous
Language - common for business and development within a single Bounded
Context. In such case an architect modeling abstractions does it already in
code - less translations, less room for waste. Code is the ultimate
representation of Domain, even when diagrams, etc. become out of date. Not to
mention that knowledge-sharing through collaboration is a fundamental process
in DDD, for which everyone is responsible.

~~~
NhanH
Is this comment a sarcastic response ? I really couldn't tell.

~~~
polskibus
It wasn't meant to be sarcastic. In my opinion coding vs knowledge architect
is false dichotomy if you embrace DDD.

~~~
DanielBMarkham
Yes and no.

Ubiquitous language depends on agreement between all the major stakeholders --
technology and business alike (That's why it's ubiquitous)

I'd shoot for that, and give DDD a pass. It's difficult, nary impossible, to
get even medium-sized groups of people in alignment in regards to language. So
do the analysis, keep working on that, and leave the code to the coders.
That's a win.

But it ain't architecture. It's analysis.

Sidebar: does anybody _do_ analysis any more? I see either complete neglect of
it, it being done as some sort of rote order-taking, or as the full-pass-
through OOA/D/P in the GP.

~~~
nickpsecurity
In case studies with formal methods, specification languages like Z are used
to make the requirements more clear. Such methods have shown to work pretty
well with both programmers and laypersons learning it easily. This means a
separate methodology or whatever might not be necessary if we just needed a
less, ambiguous language. Of which there are many with some having tool
support.

Example of one methodology that uses Z in safety-critical field with low
defect results:

[http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...](http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf)

~~~
DanielBMarkham
I think perhaps you do not understand what I am saying.

Yes, there are quite a few such tools which allow laypeople and coders to come
to an agreement. My point was about coming to and maintaining that agreement.
Not how exactly you would go about doing that.

I could think of about half-a-dozen good ways to formalize a domain. But even
if your process is nothing more than "come to this room and let's talk"? It's
difficult to get many people with many other duties in such a situation as
much as it would be required.

Don't forget -- and I'm sure you haven't -- that it's not just formalizing a
language and grammar. It's the fact that these change over time as
participants become more absorbed in the domain and see the same concepts from
various viewpoints.

~~~
polskibus
Which tools would you recommend for achieving agreement ? Any particular
technique or framework ?

------
seriousssam
Good read but it seems to me that the author escapes the difficulty of his
side of the argument by creating a God-like super-architect. Hiring someone
with the level of talent the author is describing would probably lead to great
outcomes no matter what. If the team structure is broken that person would fix
it. I'm not very familiar with the debate but I'd like to see a structure that
works for the "average" architect since most people are probably closer to
that.

~~~
no-bugs
> by creating a God-like super-architect.

Interesting point of view, never thought along these lines. On the other hand,
thinking a bit about it - I don't feel that this approach requires a super-
architect; what it requires is a DECENT architect (which is a prerequisite for
any successful project anyway).

In other words - sure, architect should be one of the best coders - but if he
isn't, the project is doomed anyway (and having "the best of the bunch" is
always possible - by definition).

------
dmgd
Reading the code of others is no substitute for writing code yourself.

It's very easy when looking at the solution to a problem to say "I would've
thought of that" and maybe you're right. But maybe not.

Having real experience of the consequences of your decisions, keeping skin in
the game, is also important. Maybe not for every single decision, but a
representative sample.

------
devonkim
Every other time I've seen architects used on the business end, you wind up
with huge messes that take a long time to produce anything of business value
while developers basically sit idle or flail around trying to build prototypes
based upon very vague ideas. This isn't to say it's useless, but YAGNI
principle is violated on the business side _very_ frequently and costs
themselves significantly. You tend to get messes that define an entire lexicon
of thought down to minutiae like DoDaF
[https://en.wikipedia.org/wiki/Department_of_Defense_Architec...](https://en.wikipedia.org/wiki/Department_of_Defense_Architecture_Framework)

------
jaegerpicker
I think this presents a false dilemma, ie it doesn't need to be coding vs non-
coding. You can code and knowledge share also. Especially if you pair program
or focus on collabitive coding techniques. It doesn't need to be one or the
other.

~~~
gedy
Yeah exactly - frankly, I think some of it may be that many teams are
micromanaged in their day-to-day, hour-to-hour tasks, and it's tough to be a
knowledge sharing leader and still code.

------
dasmoth
An interesting read, but if you're going this route how do you ensure that
there are viable career paths for senior people who prefer to focus on code
over "knowledge-sharing" kind of activities?

I suspect that part of the answer might lie in recognising that a lot of
software projects _don 't_ need a particularly scalable development approach.

~~~
no-bugs
> how do you ensure that there are viable career paths for senior people who
> prefer to focus on code over "knowledge-sharing" kind of activities?

From what I've seen, those Senior and Really Strong people who prefer to code,
do NOT even want to become architects (and to move their career beyond Really
Really Really Senior Developer - whatever the name this position carries). But
this is a different problem (at least in part related to too much
responsibility and "comfort zones"), and I don't know of any solution for
it...

------
m-i-l
I'd have thought that what the article refers to as "coding architect" would
be a dev lead in many organisations, and the role of "knowledge-sharing
architect" is the traditional software architect role, i.e. someone who comes
from a coding background and understands code well but isn't one of the core
developers (so doesn't risk getting lost in the details, becoming a
bottleneck, etc.).

~~~
_pmf_
> I'd have thought that what the article refers to as "coding architect" would
> be a dev lead in many organisations

I've seen it called "senior developer", although nowadays this is used a bit
inflationary.

