3 ms·
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
by structorg 10y ago
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 10y agoTo 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.