3 ms·

It's definitely a wonderful goal to aspire to, and ideal for small or personal projects. In my experience, I've found this particular approach to be, at times,

by Kalium 6y ago

It's definitely a wonderful goal to aspire to, and ideal for small or personal projects. In my experience, I've found this particular approach to be, at times, of unfortunately limited value in developing and maintaining enterprise systems. A previous employer of mine was a Clojure-heavy shop. There were multiple teams. A Clojure dev going from one team to another could expect to find themselves in a very different stack with very different conventions to do very similar-looking web service tasks. In essence, each team had composed their own under-documented framework.

lostcolony 6y ago
I've had no issues with it in enterprise systems. Note that it doesn't mean you can't use a framework...it just means prioritizing ones that feel more like libraries, and minimize their surface area. I've worked in a shop that had 8 dev teams, all working on different systems, all in Node, using Express. We favored standardizing, but standardizing on something easily extensible. The middleware approach made including non-standard things really easy; if I needed to include some custom authentication library that wasn't written for Express, it was trivial to do it; a couple lines of glue was all it would take, even if it included some initialization. Compare that to a Spring, say. I have to know about the framework's authentication interfaces, implement a comparatively large amount of glue in terms of those interfaces and configuration, and even more hoops to jump through if there's state I need to initialize first for the underlying library. That's what I mean. I'm not arguing for or against standardization, but extensibility and minimal cognitive overhead in extending it.
- Kalium 6y ago
  You're absolutely right. Extensibility and minimizing cognitive overhead are imperative. What I found through my experience is that offering many hooks for extensibility sometimes increased cognitive overhead for the team. With so many ways to accomplish a given task, no agreement on how to do it, and no guiding conventions, moving from one part of a repo to another can entail nontrivial cognitive overhead. Moving to a different project with a different collection of extensibility approaches employed for the minimal cognitive overhead of those authors sometimes compounds the problems. I've seen developers do things that were easy, obvious, and extensible to them but utterly incomprehensible for everyone else. Having the freedom to compose libraries as they saw fit may have made it more likely. Compare to Rails. For all its many, many warts and often exceptionally opinionated quirks, it's often relatively easy to move a junior or mid-level dev from one part of the codebase to another. Or one team to another. Or even one company to another. Many of the conventions are the same and the standards largely match, making onboarding easier. This can also make it easier for a random dev to predict how the system might be extended for a given task, easing maintenance over time. I think the core tradeoff here is between what minimizes overhead and cognitive costs for an individual and what is optimal for an organization. Also, I ran into issues with Clojure teams composing their own stacks and forgetting things like basic security measures of the sort that mature, pre-fab frameworks like Rails build in by default. They minimized the surface area so hard that they maximized the ignorance they exposed, producing services that couldn't be bothered use CSRF tokens because the developers had never heard of them. Again, I think you're right. It's about extensibility and cognitive overhead. I've just found there to be some nuance to what approach provides the best outcomes. I don't particularly enjoy being bossed around by a bucket of bits that tells me how I'm allowed to express my wishes, but I've found that my emotional experience of it isn't the important thing.

by Kalium 6y ago

lostcolony 6y ago

I've had no issues with it in enterprise systems. Note that it doesn't mean you can't use a framework...it just means prioritizing ones that feel more like libraries, and minimize their surface area. I've worked in a shop that had 8 dev teams, all working on different systems, all in Node, using Express. We favored standardizing, but standardizing on something easily extensible. The middleware approach made including non-standard things really easy; if I needed to include some custom authentication library that wasn't written for Express, it was trivial to do it; a couple lines of glue was all it would take, even if it included some initialization. Compare that to a Spring, say. I have to know about the framework's authentication interfaces, implement a comparatively large amount of glue in terms of those interfaces and configuration, and even more hoops to jump through if there's state I need to initialize first for the underlying library. That's what I mean. I'm not arguing for or against standardization, but extensibility and minimal cognitive overhead in extending it.

Kalium 6y ago
You're absolutely right. Extensibility and minimizing cognitive overhead are imperative. What I found through my experience is that offering many hooks for extensibility sometimes increased cognitive overhead for the team. With so many ways to accomplish a given task, no agreement on how to do it, and no guiding conventions, moving from one part of a repo to another can entail nontrivial cognitive overhead. Moving to a different project with a different collection of extensibility approaches employed for the minimal cognitive overhead of those authors sometimes compounds the problems. I've seen developers do things that were easy, obvious, and extensible to them but utterly incomprehensible for everyone else. Having the freedom to compose libraries as they saw fit may have made it more likely. Compare to Rails. For all its many, many warts and often exceptionally opinionated quirks, it's often relatively easy to move a junior or mid-level dev from one part of the codebase to another. Or one team to another. Or even one company to another. Many of the conventions are the same and the standards largely match, making onboarding easier. This can also make it easier for a random dev to predict how the system might be extended for a given task, easing maintenance over time. I think the core tradeoff here is between what minimizes overhead and cognitive costs for an individual and what is optimal for an organization. Also, I ran into issues with Clojure teams composing their own stacks and forgetting things like basic security measures of the sort that mature, pre-fab frameworks like Rails build in by default. They minimized the surface area so hard that they maximized the ignorance they exposed, producing services that couldn't be bothered use CSRF tokens because the developers had never heard of them. Again, I think you're right. It's about extensibility and cognitive overhead. I've just found there to be some nuance to what approach provides the best outcomes. I don't particularly enjoy being bossed around by a bucket of bits that tells me how I'm allowed to express my wishes, but I've found that my emotional experience of it isn't the important thing.