9 ms·

Software architecture pitfalls and how to avoid them

50 points by chuckhend 3y ago

PH95VuimJjqBqy 3y ago
I honestly disagree with a lot of these points. shipping software means compromise, most of these points are basically "don't compromise on X".
- danparsonson 3y ago
  Shipping software means comprises but compromising everything will result in a failure. You surely wouldn't argue that companies should compromise on developer machine specs, for example? Too many organisations cheap out somewhere on the development process in the name of "efficiency", and this article is arguing (and I agree) that that's short-sighted and will cause more trouble than it saves in the long run.
  - PH95VuimJjqBqy 3y ago
    I wonder if there's at term for this type of repsonse. I most obviously did not say, or mean, every piece of software shipped must have every single part of it compromised in some manner.
    - danparsonson 3y ago
      My mistake. I read > shipping software means compromise, most of these points are basically "don't compromise on X". as, you disagree with a lot of the article because it's telling you not to compromise on some things and compromises are necessary for software development. That only logically works if you're also saying that compromises are necessary everywhere, doesn't it? Otherwise what's to disagree on? If you're saying compromise may be required on any of items 1 through 10, and I'm telling you not to compromise on 1-5, well then 6-10 are your zones of flexibility.
      - PH95VuimJjqBqy 3y ago
        I certainly don't think the 12 points brought up in the article are everything and therefore any interpretation of my comment as applying to everything is unreasonable. If your stance is "always do X" then you can replace yourself with a post-it note. Just write "always do X" on the post-it note, then when you have a decision point, refer to it. You're done. Actual engineering is about weaving through constraints and goals and that often implies compromises. Someone who can do that well cannot be replaced by a post-it note. And guess what "always compromise" can also be placed on a post-it note so very obviously that is not what I'm saying. don't be replace-able by a post-it note.
supersparrow 3y ago
> People who are not building the architecture should not make decisions about it. Nope! Everyone can and does make mistakes. A good architect should accept and learn from suggestions and ultimately better technical decisions put forward by members of the team, whether it’s the senior with 70 years experience or the 1-month experience, bright junior with a good idea. I was in a team where the architect chose to use React without TypeScript, and a nasty .NET 4/React mix for the front end. This was 2-3 years ago. I suppose it’s what he knew and was comfortable with? This combination caused no end of issues and an unnecessarily difficult development process. Unfortunately I wasn’t around at the time, but I’d have spoken up, and probably been listened to, which is what i’d expect from any good team, regardless of your position. Better is better, doesn’t matter whose mouth it comes out of. A lot of the architects I’ve worked with have been rather snobby and quick to dismiss less experienced team members in my experience.
mynameisnoone 3y ago
Don't work at megacorps where people are incentivized to ship big milestone branded projects and "quantifiable" impact because you will end up with massive codebases that are never refactored, over-engineered with such failures as code generation and abstract interfaces for everything, and keep layering on crap while tech debt entropy maximizes and relative agility grinds to a halt.
- jongjong 3y ago
  Agreed. Big tech is not were you learn good coding. There's no way they can recover from it. Most HR people there have no idea what they're doing and devs are all political and self-interest and it's probably full of foreign intelligence operatives who are interested in complexity as it helps them to hide backdoors all over the place.
  - totetsu 3y ago
    How many documented public cases are there of intelligence operatives hiding backdoors in things.
    - halfcat 3y ago
      None. That’s how you know they’re good at hiding them.
    - mynameisnoone 3y ago
      Does Dual_EC_DRBG count?
  - mynameisnoone 3y ago
    TripleByte flails its arms and says it can help. I still think there ought to be formalized, international journeyman and apprenticeship programs for SWE, HWE, SRE, QA, product management, project management, and technical management independent of employer. The lack of generational knowledge and culture transfer leads to droves of novices learning bad habits.
Joel_Mckay 3y ago
There are many failure modes, and by the time you show up... the entrenched incompetence will constrain the options within current project inertia and budgets. Usually, it is better to branch a separate "new" team in another space, functionally deprecate the old project one feature at a time, and jettison the previous team including the manager after 6 months of uptime. Trying to untangle a mess often takes 7 times longer than simply re-building a better version with well defined use-cases. =)
- Arrgh 3y ago
  Counterpoint: the new project has to survive long enough to ship 1.0. :/
  - Joel_Mckay 3y ago
    Sometimes a company is not worth saving, and it is better to reject the project before the stench stains your reputation. https://www.youtube.com/watch?v=6D9vAItORgE https://www.youtube.com/watch?v=6D9vAItORgE =)
- PH95VuimJjqBqy 3y ago
  > by the time you show up... the entrenched incompetence will constrain the options within current project inertia and budgets. this is so true, but sometimes the incompetence is so bad it's not feasible to build a competent team (very very difficult at least). I'm actually in the middle of this now and I have to tell you, I've been doing this for 25+ years and I'm absolutely flabbergasted that people with this level of incompetence are gainfully employed in this industry. It's so bad we have contractor teams running circles around them and by circles I mean 2-3x their velocity with code designs that are as good or better.
  - Joel_Mckay 3y ago
    "I've been doing this for 25+" Indeed, people from the early days actually know how a computer is internally structured. I seriously consider becoming a Plumber everyday. Had to develop esoteric personal projects to find the fun. =)
jamestimmins 3y ago
Meta: I love this style of article and I wish it was more common and in more detail. "How to build perfect software in Django" is incredibly hard to write, but "15 common Django architectural mistakes" is a lot easier to write is extremely useful.
- jayd16 3y ago
  Have we gone full circle? "10 hot tips for the perfect app" was a style that was so over used and clickbaity that HN rewrites the title to remove the count.
  - jamestimmins 3y ago
    I think my comment was unclear. I don't find the listicle to be the interesting part; rather, articles that focus on anti-patterns. A lot of architectural mistakes are because people make fairly straightforward mistakes that could be easily avoided with good resources focused on what not to do.
- 1920musicman 3y ago
  IMO "15 common Django architectural mistakes" is a less useful focus for these types of posts. Architecture can't be taught by listing quick tips. Or at least not only by listing quick tips. The unfortunate reality is that in many (most?) cases when inexperienced engineers face these challenges, it's too late to follow quick tips... their company's Django app has been set up 10 years prior, and now they have dozens upon dozens of layers of abstraction in the codebase. Teaching how to think about architecture, how to evaluate options and how to make decisions is a more reliable and applicable skill.
  - jamestimmins 3y ago
    It definitely wouldn't be sufficient on it's own, so it's no substitute to understanding architecture. I think it's more a useful technique for ways of learning architecture that is often underexplored. Most posts focus on what to do, and few seem to focus on what not to do. Shifting the balance somewhat would be valuable IMO.
bigEnotation 3y ago
What’s a quality attribute requirement, and how are they usually documented and prioritized?
- jbmsf 3y ago
  Right? That seems to be the thing this article is advocating and I have no idea what they are.
- 1920musicman 3y ago
  In systems design quality attributes are non-functional requirements that are used for the evaluation of the system itself rather than the intended behavior of the feature being implemented. E.g. system extensibility, scalability are quality attributes.
- deleted 3y ago
  [deleted]
- Const-me 3y ago
  From the context I assumed these are the things I knew as “non-functional requirements”. Basically, random stuff which doesn’t have specific associated use cases. Depending on the project, they might specify environment, setup and deployment, throughput and latency, system requirements, security, reliability, compliance, etc.
1920musicman 3y ago
> there’s a big difference between having ten years of experience and having one year of experience repeated ten times Love this thought! It's surprisingly common to meet engineers with 6-7 years of experience with incredibly bad habits that they picked up working essentially at a single company that they joined right out of college. Repeating the same questionable patterns for 6 years doesn't provide a lot of growth opportunity. In this context, FAANG's obsession with hiring new grads is a questionable practice, people get stuck.
- roncesvalles 3y ago
  I will always value someone who has worked at 5 companies for 2 years each more than someone who has worked at the same company for 10 years. Most of the learning in any job happens during the first year. Imagine someone who has onboarded 5 times into 5 different company cultures and architectural systems. Such a person is a walking software engineering textbook.
  - medler 3y ago
    So you actually see “1 year of experience repeated 10 times” as a positive! I like that, but do I think there’s value in thinking about how a system should evolve over the long term and in seeing the long-term consequences of your own architectural decisions.
    - stouset 3y ago
      I’ve seen this play out so many times I’m tired of it. New team member joins. Super “productive”, rewrites enormous chunks of existing code and builds six new things. Great. Then they leave, and you find out the bits they rewrote were the carefully crafted and well documented protobuf APIs now replaced by ad hoc JSON where the parsing and spec are strewn across thirty places. The new projects you quickly realize make no sense whatsoever and don’t actually do the things they were supposed to do, but kind of look like it if you aren’t paying too close attention. Now they’re a “senior engineer” at the next company.
    - PH95VuimJjqBqy 3y ago
fallingknife 3y ago
In my experience the big one is, if a monolith will work, build a monolith.
- randomdata 3y ago
  Unless your project complexity is on the order of blinking an LED, there isn't enough time in the day for a monolith, I'm afraid. You are going to have to build in coordination with other services (OSes, DMBSes, etc.) It is a nice idea, but totally impractical.
  - feoren 3y ago
    Highlight all the code you have written / are responsible for. Have you highlighted just one single project that gets deployed as one unit? Then you have a monolith. Monolith doesn't mean you never talk to other services; it means you only own one.
    - deleted 3y ago
      [deleted]
    - randomdata 3y ago
      My coworker highlighted just one single project that gets deployed as one unit. I have a second hobby project I work on at home of which I also take ownership. He is building a monolith, I am not? Even though we are working on the exact same project? Um. Okay. So, just so I am clear, the advice here can be rephrased as: "Save a matter of life or death, don't have hobbies"?
      - feoren 3y ago
        I think you know what I meant. If you want exact definitions of words, study math.
  - fallingknife 3y ago
    You can use Rails/Django/NextJS + Postgres/Mysql and while I guess that's not technically a monolith, everybody calls it that anyway because the coordination is pretty much abstracted out. And that's gonna get you pretty far. If you really wanted it to be a monolith, you could use sqlite and that would actually get you pretty far too, but why would you when postgres/mysql is just as easy and will scale so much further?
theflork 3y ago
i used to work with these so called "software architects". they didnt ship any code but wrote articles like this at length that everyone pretended to read.
- mp05 3y ago
  To be fair, some are busy reviewing PRs.
- ubercow13 3y ago
  Every role has good or bad practitioners no? eg, I have worked with many so called 'developers'. They shipped lots of code, but most of it was solving the wrong problem, didn't fit any business requirement, added unnecessary complexity, had to be replaced almost immediately, etc. etc.
0xbadcafebee 3y ago
It's ironic that they use pictures of failing bridges, after describing software architecture practices which are never used to build bridges. Yes, let's experiment with this 300 million dollar bridge for a few years, and make sure the construction workers are part of defining the fill type and dimensions of the structural pillars. The way I wish software were created is more like physical infrastructure. There's still huge problems with construction, to be sure. But it lasts longer and is more likely to succeed when completed. There's all kinds of requirements, analysis, and inspection to ensure it works correctly. The people putting it together don't need to be very skilled; they're working with off-the-shelf commodity parts, manufactured to a minimum specification, with specific dimensions and attributes, which loosely couple in many configurations with identical parts from different vendors all over the world. Combining them in specific ways has quantifiable, predetermined results. And you know that for the parts that require being designed correctly, the people designing them had very specific minimum qualifications that take years to attain. Companies today, whenever they want to build a software product, think they need to build an entire factory first. But companies making physical products wouldn't do that, because building a factory requires factory-building skill, that has nothing to do with the widget they want to make. Instead they would find a factory and hire them to build their widget. Software may be "modern", but its production is antiquated.
- dasil003 3y ago
  I hear you, but the promise and curse of software is that it is malleable. We are not building bridges with extremely clear and obvious success and failure, we are creating user experiences that vary subjectively based on who is using them and what other digital or physical realities they interact with. It's an alluring fantasy that if we just let the seasoned experts design everything and gave them space to work, we could have better quality systems. This is not how it plays out though, you get burned from both sides. Inevitably some non-technical leadership stakeholders ask very fair questions about "why can't we just...", and they're not wrong about what's possible, it's just different from what came before and it's not possible to rebuild entire digital systems as quickly as the good ideas come. On the implementation side, details matter and abstractions leak, seemingly small requirement changes undermine assumptions behind major architectural decisions. The idea that you can have a handful of seasonsed experts guiding an army of low-skill builders just doesn't work out with the same economics of physical construction. The details matter too much, and the implications of pure logic are too diverse to be covered by the equivalent of physical building codes.
Log_out_ 3y ago
? Article does not talk about pitfalls of architecture, proceeds to talk about hierarchical processes in organization. Guess it's a failure to uphold and implement layers of abstractions. Good thing there is a software engineer to distribute knowledge on software development process engineering. The failure of the article is the article.

50 points by chuckhend 3y ago

I honestly disagree with a lot of these points. shipping software means compromise, most of these points are basically "don't compromise on X".

danparsonson 3y ago
Shipping software means comprises but compromising everything will result in a failure. You surely wouldn't argue that companies should compromise on developer machine specs, for example? Too many organisations cheap out somewhere on the development process in the name of "efficiency", and this article is arguing (and I agree) that that's short-sighted and will cause more trouble than it saves in the long run.
- PH95VuimJjqBqy 3y ago
  I wonder if there's at term for this type of repsonse. I most obviously did not say, or mean, every piece of software shipped must have every single part of it compromised in some manner.
  - danparsonson 3y ago
    My mistake. I read > shipping software means compromise, most of these points are basically "don't compromise on X". as, you disagree with a lot of the article because it's telling you not to compromise on some things and compromises are necessary for software development. That only logically works if you're also saying that compromises are necessary everywhere, doesn't it? Otherwise what's to disagree on? If you're saying compromise may be required on any of items 1 through 10, and I'm telling you not to compromise on 1-5, well then 6-10 are your zones of flexibility.
    - PH95VuimJjqBqy 3y ago
      I certainly don't think the 12 points brought up in the article are everything and therefore any interpretation of my comment as applying to everything is unreasonable. If your stance is "always do X" then you can replace yourself with a post-it note. Just write "always do X" on the post-it note, then when you have a decision point, refer to it. You're done. Actual engineering is about weaving through constraints and goals and that often implies compromises. Someone who can do that well cannot be replaced by a post-it note. And guess what "always compromise" can also be placed on a post-it note so very obviously that is not what I'm saying. don't be replace-able by a post-it note.

supersparrow 3y ago

> People who are not building the architecture should not make decisions about it. Nope! Everyone can and does make mistakes. A good architect should accept and learn from suggestions and ultimately better technical decisions put forward by members of the team, whether it’s the senior with 70 years experience or the 1-month experience, bright junior with a good idea. I was in a team where the architect chose to use React without TypeScript, and a nasty .NET 4/React mix for the front end. This was 2-3 years ago. I suppose it’s what he knew and was comfortable with? This combination caused no end of issues and an unnecessarily difficult development process. Unfortunately I wasn’t around at the time, but I’d have spoken up, and probably been listened to, which is what i’d expect from any good team, regardless of your position. Better is better, doesn’t matter whose mouth it comes out of. A lot of the architects I’ve worked with have been rather snobby and quick to dismiss less experienced team members in my experience.

mynameisnoone 3y ago

Don't work at megacorps where people are incentivized to ship big milestone branded projects and "quantifiable" impact because you will end up with massive codebases that are never refactored, over-engineered with such failures as code generation and abstract interfaces for everything, and keep layering on crap while tech debt entropy maximizes and relative agility grinds to a halt.

jongjong 3y ago
Agreed. Big tech is not were you learn good coding. There's no way they can recover from it. Most HR people there have no idea what they're doing and devs are all political and self-interest and it's probably full of foreign intelligence operatives who are interested in complexity as it helps them to hide backdoors all over the place.
- totetsu 3y ago
  How many documented public cases are there of intelligence operatives hiding backdoors in things.
  - halfcat 3y ago
    None. That’s how you know they’re good at hiding them.
  - mynameisnoone 3y ago
    Does Dual_EC_DRBG count?
- mynameisnoone 3y ago
  TripleByte flails its arms and says it can help. I still think there ought to be formalized, international journeyman and apprenticeship programs for SWE, HWE, SRE, QA, product management, project management, and technical management independent of employer. The lack of generational knowledge and culture transfer leads to droves of novices learning bad habits.

Joel_Mckay 3y ago

There are many failure modes, and by the time you show up... the entrenched incompetence will constrain the options within current project inertia and budgets. Usually, it is better to branch a separate "new" team in another space, functionally deprecate the old project one feature at a time, and jettison the previous team including the manager after 6 months of uptime. Trying to untangle a mess often takes 7 times longer than simply re-building a better version with well defined use-cases. =)

Arrgh 3y ago
Counterpoint: the new project has to survive long enough to ship 1.0. :/
- Joel_Mckay 3y ago
  Sometimes a company is not worth saving, and it is better to reject the project before the stench stains your reputation. https://www.youtube.com/watch?v=6D9vAItORgE https://www.youtube.com/watch?v=6D9vAItORgE =)
PH95VuimJjqBqy 3y ago
> by the time you show up... the entrenched incompetence will constrain the options within current project inertia and budgets. this is so true, but sometimes the incompetence is so bad it's not feasible to build a competent team (very very difficult at least). I'm actually in the middle of this now and I have to tell you, I've been doing this for 25+ years and I'm absolutely flabbergasted that people with this level of incompetence are gainfully employed in this industry. It's so bad we have contractor teams running circles around them and by circles I mean 2-3x their velocity with code designs that are as good or better.
- Joel_Mckay 3y ago
  "I've been doing this for 25+" Indeed, people from the early days actually know how a computer is internally structured. I seriously consider becoming a Plumber everyday. Had to develop esoteric personal projects to find the fun. =)

jamestimmins 3y ago

Meta: I love this style of article and I wish it was more common and in more detail. "How to build perfect software in Django" is incredibly hard to write, but "15 common Django architectural mistakes" is a lot easier to write is extremely useful.

jayd16 3y ago
Have we gone full circle? "10 hot tips for the perfect app" was a style that was so over used and clickbaity that HN rewrites the title to remove the count.
- jamestimmins 3y ago
  I think my comment was unclear. I don't find the listicle to be the interesting part; rather, articles that focus on anti-patterns. A lot of architectural mistakes are because people make fairly straightforward mistakes that could be easily avoided with good resources focused on what not to do.
1920musicman 3y ago
IMO "15 common Django architectural mistakes" is a less useful focus for these types of posts. Architecture can't be taught by listing quick tips. Or at least not only by listing quick tips. The unfortunate reality is that in many (most?) cases when inexperienced engineers face these challenges, it's too late to follow quick tips... their company's Django app has been set up 10 years prior, and now they have dozens upon dozens of layers of abstraction in the codebase. Teaching how to think about architecture, how to evaluate options and how to make decisions is a more reliable and applicable skill.
- jamestimmins 3y ago
  It definitely wouldn't be sufficient on it's own, so it's no substitute to understanding architecture. I think it's more a useful technique for ways of learning architecture that is often underexplored. Most posts focus on what to do, and few seem to focus on what not to do. Shifting the balance somewhat would be valuable IMO.

bigEnotation 3y ago

What’s a quality attribute requirement, and how are they usually documented and prioritized?

jbmsf 3y ago
Right? That seems to be the thing this article is advocating and I have no idea what they are.
1920musicman 3y ago
In systems design quality attributes are non-functional requirements that are used for the evaluation of the system itself rather than the intended behavior of the feature being implemented. E.g. system extensibility, scalability are quality attributes.
deleted 3y ago
[deleted]
Const-me 3y ago
From the context I assumed these are the things I knew as “non-functional requirements”. Basically, random stuff which doesn’t have specific associated use cases. Depending on the project, they might specify environment, setup and deployment, throughput and latency, system requirements, security, reliability, compliance, etc.

1920musicman 3y ago

> there’s a big difference between having ten years of experience and having one year of experience repeated ten times Love this thought! It's surprisingly common to meet engineers with 6-7 years of experience with incredibly bad habits that they picked up working essentially at a single company that they joined right out of college. Repeating the same questionable patterns for 6 years doesn't provide a lot of growth opportunity. In this context, FAANG's obsession with hiring new grads is a questionable practice, people get stuck.

roncesvalles 3y ago
I will always value someone who has worked at 5 companies for 2 years each more than someone who has worked at the same company for 10 years. Most of the learning in any job happens during the first year. Imagine someone who has onboarded 5 times into 5 different company cultures and architectural systems. Such a person is a walking software engineering textbook.
- medler 3y ago
  So you actually see “1 year of experience repeated 10 times” as a positive! I like that, but do I think there’s value in thinking about how a system should evolve over the long term and in seeing the long-term consequences of your own architectural decisions.
  - stouset 3y ago
    I’ve seen this play out so many times I’m tired of it. New team member joins. Super “productive”, rewrites enormous chunks of existing code and builds six new things. Great. Then they leave, and you find out the bits they rewrote were the carefully crafted and well documented protobuf APIs now replaced by ad hoc JSON where the parsing and spec are strewn across thirty places. The new projects you quickly realize make no sense whatsoever and don’t actually do the things they were supposed to do, but kind of look like it if you aren’t paying too close attention. Now they’re a “senior engineer” at the next company.
  - PH95VuimJjqBqy 3y ago

fallingknife 3y ago

In my experience the big one is, if a monolith will work, build a monolith.

randomdata 3y ago
Unless your project complexity is on the order of blinking an LED, there isn't enough time in the day for a monolith, I'm afraid. You are going to have to build in coordination with other services (OSes, DMBSes, etc.) It is a nice idea, but totally impractical.
- feoren 3y ago
  Highlight all the code you have written / are responsible for. Have you highlighted just one single project that gets deployed as one unit? Then you have a monolith. Monolith doesn't mean you never talk to other services; it means you only own one.
  - deleted 3y ago
    [deleted]
  - randomdata 3y ago
    My coworker highlighted just one single project that gets deployed as one unit. I have a second hobby project I work on at home of which I also take ownership. He is building a monolith, I am not? Even though we are working on the exact same project? Um. Okay. So, just so I am clear, the advice here can be rephrased as: "Save a matter of life or death, don't have hobbies"?
    - feoren 3y ago
      I think you know what I meant. If you want exact definitions of words, study math.
- fallingknife 3y ago
  You can use Rails/Django/NextJS + Postgres/Mysql and while I guess that's not technically a monolith, everybody calls it that anyway because the coordination is pretty much abstracted out. And that's gonna get you pretty far. If you really wanted it to be a monolith, you could use sqlite and that would actually get you pretty far too, but why would you when postgres/mysql is just as easy and will scale so much further?

theflork 3y ago

i used to work with these so called "software architects". they didnt ship any code but wrote articles like this at length that everyone pretended to read.

mp05 3y ago
To be fair, some are busy reviewing PRs.
ubercow13 3y ago
Every role has good or bad practitioners no? eg, I have worked with many so called 'developers'. They shipped lots of code, but most of it was solving the wrong problem, didn't fit any business requirement, added unnecessary complexity, had to be replaced almost immediately, etc. etc.

0xbadcafebee 3y ago

It's ironic that they use pictures of failing bridges, after describing software architecture practices which are never used to build bridges. Yes, let's experiment with this 300 million dollar bridge for a few years, and make sure the construction workers are part of defining the fill type and dimensions of the structural pillars. The way I wish software were created is more like physical infrastructure. There's still huge problems with construction, to be sure. But it lasts longer and is more likely to succeed when completed. There's all kinds of requirements, analysis, and inspection to ensure it works correctly. The people putting it together don't need to be very skilled; they're working with off-the-shelf commodity parts, manufactured to a minimum specification, with specific dimensions and attributes, which loosely couple in many configurations with identical parts from different vendors all over the world. Combining them in specific ways has quantifiable, predetermined results. And you know that for the parts that require being designed correctly, the people designing them had very specific minimum qualifications that take years to attain. Companies today, whenever they want to build a software product, think they need to build an entire factory first. But companies making physical products wouldn't do that, because building a factory requires factory-building skill, that has nothing to do with the widget they want to make. Instead they would find a factory and hire them to build their widget. Software may be "modern", but its production is antiquated.

dasil003 3y ago
I hear you, but the promise and curse of software is that it is malleable. We are not building bridges with extremely clear and obvious success and failure, we are creating user experiences that vary subjectively based on who is using them and what other digital or physical realities they interact with. It's an alluring fantasy that if we just let the seasoned experts design everything and gave them space to work, we could have better quality systems. This is not how it plays out though, you get burned from both sides. Inevitably some non-technical leadership stakeholders ask very fair questions about "why can't we just...", and they're not wrong about what's possible, it's just different from what came before and it's not possible to rebuild entire digital systems as quickly as the good ideas come. On the implementation side, details matter and abstractions leak, seemingly small requirement changes undermine assumptions behind major architectural decisions. The idea that you can have a handful of seasonsed experts guiding an army of low-skill builders just doesn't work out with the same economics of physical construction. The details matter too much, and the implications of pure logic are too diverse to be covered by the equivalent of physical building codes.

Log_out_ 3y ago

? Article does not talk about pitfalls of architecture, proceeds to talk about hierarchical processes in organization. Guess it's a failure to uphold and implement layers of abstractions. Good thing there is a software engineer to distribute knowledge on software development process engineering. The failure of the article is the article.