4 ms·

I’ve seen this model tried time and time again, though typically with an in-house “framework” rather than a language, which is a better approach anyway. It’s th

I’ve seen this model tried time and time again, though typically with an in-house “framework” rather than a language, which is a better approach anyway. It’s the “smart people build the foundation, dumb people customize with it” model. It doesn’t work well. The reason is that the “smart” people building the framework end up spiraling off into ivory tower land. They put a lot of effort into making common patterns easy. But in so doing, they make the framework’s internals hard to understand. They also become disconnected from customer reality. Meanwhile, the “dumb” people serving customer needs end up having to work around the framework in order to accomplish what they want. Because the framework is impenetrable, and because they’re junior, they end up make horrific balls of mud. It’s better to have cross-functional teams composed of a mix of skill sets, that can both focus on customer needs and build the underlying abstractions needed to make that easy. This also allows the junior folks to learn from the senior folks.

williamcotton 4y ago
> though typically with an in-house “framework” rather than a language, which is a better approach anyway. I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. > The reason is that the “smart” people building the framework end up spiraling off into ivory tower land. I don't think this is about smart vs. not smart. It's about different disciplines and abilities. Product developers should also be doing more (or all) product work and interacting with customers. > They also become disconnected from customer reality. Computer engineers who are creating a language and runtime should be servicing the specific domain of that the product. Part of the disconnect with DevOps is that it is solving for deploying general purpose tools rather than a specific domain. Have the computer engineers responsible for creating domain specific tools as well as deploying those domain specific tools and everyone should be more connected to the final outcome.
- KptMarchewa 4y ago
  >I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.
  - williamcotton 4y ago
    I'm not sure how you got "unable to perform their work" from what I was suggesting. A/B testing, analytics, CRUD, etc, are all features that are ancillary to any products that need to be made. Imagine if a language had A/B testing baked right into it. You define a couple of functions annotated for A/B testing and they are automatically A/B tested. Putting all of this inline with product functionality is generally what causes these balls of mud in the first place.
    - jdlshore 4y ago
      I think you’re overestimating the value of building such support into a language, rather than using libraries/frameworks, and underestimating the difficulty of creating bespoke languages. Speaking as someone who’s actually tried what you’re suggesting—in a production project—and learned not to do it again, this whole conversation smacks of theory-crafting rather than practical experience. But I invite you to try it!

williamcotton 4y ago

> though typically with an in-house “framework” rather than a language, which is a better approach anyway. I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. > The reason is that the “smart” people building the framework end up spiraling off into ivory tower land. I don't think this is about smart vs. not smart. It's about different disciplines and abilities. Product developers should also be doing more (or all) product work and interacting with customers. > They also become disconnected from customer reality. Computer engineers who are creating a language and runtime should be servicing the specific domain of that the product. Part of the disconnect with DevOps is that it is solving for deploying general purpose tools rather than a specific domain. Have the computer engineers responsible for creating domain specific tools as well as deploying those domain specific tools and everyone should be more connected to the final outcome.

KptMarchewa 4y ago
>I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud. Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.
- williamcotton 4y ago
  I'm not sure how you got "unable to perform their work" from what I was suggesting. A/B testing, analytics, CRUD, etc, are all features that are ancillary to any products that need to be made. Imagine if a language had A/B testing baked right into it. You define a couple of functions annotated for A/B testing and they are automatically A/B tested. Putting all of this inline with product functionality is generally what causes these balls of mud in the first place.
  - jdlshore 4y ago
    I think you’re overestimating the value of building such support into a language, rather than using libraries/frameworks, and underestimating the difficulty of creating bespoke languages. Speaking as someone who’s actually tried what you’re suggesting—in a production project—and learned not to do it again, this whole conversation smacks of theory-crafting rather than practical experience. But I invite you to try it!