4 ms·
The strong and weak forces of architecture
- ghostly_s 5y agoSorry if I seem pedantic, but this guy is not an "architect," and calling himself such is illegal in most or all US states.
- LegitShady 5y agoagreed. Also, taking titles that you don't qualify for is a red flag to me.
- syspec 5y agoNow that you mention it, flight attendants, never seem to be tending to the flight, always in the back with the passengers. Someone alert the press!
- LegitShady 5y agoNot exactly a regulated profession like engineers or architects, but if computer guys want to call themselves computer attendants you go ahead smart guy.
- gwill 5y agowhat is your stance on software "engineer" as a title? is it ok because of the _software_ qualifier? i feel like this guy just abbreviated his title given the domain of readers.
- LegitShady 5y agoIn my jurisdiction (indeed in my entire country) it's illegal unless they're actually recognized by the engineering licensing org. The only people who are allowed to call themselves engineers without being recognized professional members of the engineering association are a type of plane mechanic with federal certification which supersedes provincial law that restricts who can call themselves engineer. Where I live it would be illegal for them to call themselves engineers unless they were professional engineers as recognized by the provincial engineering certification body which was created a law passed by the provincial legislature. The provincial engineering org does have a computer designation, so they could get licensed and have it official if they were computer engineers, but I'm not sure about software.
- jdougan 5y agoHe is obviously shorthanding Software Architect or Information Architect here. It clearly has nothing to do with actual buildings or other civil structures and he isn't using the legal label either (eg. "Licensed Professional Architect" in California).
- chrisin2d 5y agoI think that while your common sense is correct, the title of just "Architect" is protected legally. To become a licensed Architect, one must have a degree from an NAAB-accredited program, complete 3,740 hours under the guidance of an Architect, and complete a long and difficult 7-part exam. He can call himself a Software Architect, Information Architect, Technology Architect, or any other variation — but he is not allowed to call himself just Architect and can be sued for doing so.
- arcticfox 5y agoThis type of pedantic and overzealous gatekeeping, with no benefit to the public, got slapped down in US District Court. You can't just take over basic English words. https://www.techspot.com/news/78096-oregon-engineer-wins-freedom-speech-lawsuit-against-overzealous.html https://www.techspot.com/news/78096-oregon-engineer-wins-fre...
- ownagefool 5y agoI mean, either way the guys not in the US, and the sites owned by an English guy ( who to be fair, does now appear to live in the US, so the entire thread makes no sense unless you start from the position that the US owns all of English language.
- tomnipotent 5y ago> the title of just "Architect" is protected legally. Only if you're using the title to represent yourself as a certified architect, and no one in the public is going to be confused about what a software architect does and hire them to build a bridge. Otherwise, no, it's not legally protected and even then it varies by state. I can legally start a match making company and have the title "Architect" without facing any legal consequences.
- arcticfox 5y agoThe laws prohibiting that are actually themselves probably in violation of federal case law (1st Amendment based), in case you want to follow your pedantic thread to the end https://www.techspot.com/news/78096-oregon-engineer-wins-freedom-speech-lawsuit-against-overzealous.html https://www.techspot.com/news/78096-oregon-engineer-wins-fre...
- rackjack 5y ago9 comments and all are about pedantry. I found the article interesting, and I wonder if anybody with more experience could give their 2 cents.
- joneil 5y agoThat was a helpful read, thanks. My company (also in Melbourne!) is probably one stage of growth beneath this. We have “verticals” and “teams” but don’t really have the layer in the middle yet (“domains”). As we’ve grown from only a few teams, to multiple verticals, we’ve tried to jump straight from unclear boundaries and implicit APIs to fully versioned services and packages. Thinking about these as solutions to communication problems, where the problems differ in degree depending on the number of teams interacting with it, is a useful way of framing the discussions. Hopefully it brings some clarity to discussions about when the light-and-loose methods are okay, and when the more heavy processes are justified.
- sjtindell 5y agoHugely not a fan of inserting your profile at the very top. Good content though.
- TheSpiceIsLife 5y agoOn the other hand, how many times recently have we seen comments here to the effect: this reads like it was written by a high schooler with an axe to grind. The context of who wrote a piece can be helpful.
- Floegipoky 5y agoI definitely see these forces at work at my current gig. In our context the lines separating what should be domain-specific boundaries are blurry. The main system is a monolithic codebase which was developed with a "wild west architecture" for over a decade before engineering leadership realized the tech debt was interfering with feature development. We've tried to draw domain boundaries but that initial lack of discipline meant that things were too far gone to easily separate them, and senior leadership has never been willing to invest in paying down this debt. The points about shared tech and infrastructure hit pretty hard because it's a single monorepo deployed to homogeneous application servers. When we do bump up against issues with infrastructure we almost always end up building one-off shims. Our architects call them Microservices. Code contribution is messy too. For any given feature, core functionality is typically owned by one team along with some of the downstream effects. The rest of the downstream effects are owned by other teams scattered across different verticals and often continents. It's rarely safe to change the core functionality of a feature by itself. Dysfunctional politics leads to projects getting delayed because of miscommunication and different priorities, and we can't risk encroaching on someone else's fiefdom. I recently burned a lot of political capital doing just that because a critical deadline was at risk.
- physicsgraph 5y agoThe proposal seems to be that software design guidance correspond to existing hierarchical organization structure. A formalization of Conway's Law [0]. The more people in the hierarchy that coordination touches, the looser the coupling. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law