Knowledge-Sharing Architects as an Alternative to Coding Architects | Hacker News Reader

Knowledge-Sharing Architects as an Alternative to Coding Architects

ithare.com

61 pointssigna1124 comments

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.

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.

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.

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

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

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.

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

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.

Thanks for clarifying. Those are good points.

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

WTF is OOA/D/P in the GP? Is that a thing?

hint: google for OOA

I see what you're saying as that thought occurred to me haha. Only thing that kept me from saying what you did is that it sounds very similar to model-driven development. Plus, I bumped into it here:

https://en.wikipedia.org/wiki/List_of_software_development_p...

Followed by this:

https://en.wikipedia.org/wiki/Domain-driven_design

There was a company that I had bookmarked that did enterprise software by defining ontologies that got converted into code or something. I can't find it but this link seems similar. Stuff does have some use in actual applications.

http://www.mkbergman.com/948/ontology-driven-apps-using-gene...

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.

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

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.

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

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.

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.

> You can code and knowledge share also.

The problem with it is that there are only 24 hours in a day.

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.

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

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

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

Reply on news.ycombinator.com