I wish I could upvote this article 1000 times - definitely the best thing I've read all year. My favorite quotes:
"Features interact — intentionally — and that makes the cost of implementing the N+1 feature closer to N than 1."
(When explaining to folks why it takes longer to build something in the CRM than as a standalone app - you realize the standalone just won't work with 10 critical features, right?)
"What I found is that advocates for these new technologies tended to confuse the productivity benefits of working on a small code base (small N essential complexity due to fewer feature interactions and small N cost for features that scale with size of codebase) with the benefits of the new technology itself — efforts using a new technology inherently start small so the benefits get conflated."
This describes like 20% of the articles that make it on hacker news. Or maybe 20% of the ones I read. Might be a personal problem.
"So 'free code' tends to be 'free as in puppy' rather than 'free as in beer'."
Anyone debugging js build chains or trying to fix ng1 performance after you get out of the toy app stage can probably relate.
"Bill wanted (still wants) a breakthrough in how we build rich productivity apps. He expected that the shape of that breakthrough would be to build a highly functional component that would serve as the core engine for all the applications. For a time he believed that Trident (the core engine for Internet Explorer) could become that component. That model leads you to invest in building a more and more functional component that represents more and more of the overall application (and therefore results in more of the cost of building each application being shared across all applications).
This view that I have described here of increasing feature interaction causing increasing essential complexity leads to the conclusion that such a component would end up suffering from the union of all the complexity and constraints of the masters it needs to serve. Ultimately it collapses of its own weight. The alternate strategy is to emphasize isolating complexity, creating simpler functional components, and extracting and refactoring sharable components on an ongoing basis."
It is super common to see people want to do Big Framework Up Front design for applications, and then find out that the framework makes things slower for the primary use case than the old, "crappy" way, aside from the cost/opportunity cost of spending all that time on a framework instead of business value. I guess it makes me feel a little better than Bill Gates also suffers from that delusion.
"Features interact — intentionally — and that makes the cost of implementing the N+1 feature closer to N than 1."
(When explaining to folks why it takes longer to build something in the CRM than as a standalone app - you realize the standalone just won't work with 10 critical features, right?)
"What I found is that advocates for these new technologies tended to confuse the productivity benefits of working on a small code base (small N essential complexity due to fewer feature interactions and small N cost for features that scale with size of codebase) with the benefits of the new technology itself — efforts using a new technology inherently start small so the benefits get conflated."
This describes like 20% of the articles that make it on hacker news. Or maybe 20% of the ones I read. Might be a personal problem.
"So 'free code' tends to be 'free as in puppy' rather than 'free as in beer'."
Anyone debugging js build chains or trying to fix ng1 performance after you get out of the toy app stage can probably relate.
"Bill wanted (still wants) a breakthrough in how we build rich productivity apps. He expected that the shape of that breakthrough would be to build a highly functional component that would serve as the core engine for all the applications. For a time he believed that Trident (the core engine for Internet Explorer) could become that component. That model leads you to invest in building a more and more functional component that represents more and more of the overall application (and therefore results in more of the cost of building each application being shared across all applications).
This view that I have described here of increasing feature interaction causing increasing essential complexity leads to the conclusion that such a component would end up suffering from the union of all the complexity and constraints of the masters it needs to serve. Ultimately it collapses of its own weight. The alternate strategy is to emphasize isolating complexity, creating simpler functional components, and extracting and refactoring sharable components on an ongoing basis."
It is super common to see people want to do Big Framework Up Front design for applications, and then find out that the framework makes things slower for the primary use case than the old, "crappy" way, aside from the cost/opportunity cost of spending all that time on a framework instead of business value. I guess it makes me feel a little better than Bill Gates also suffers from that delusion.