4 ms·

As the maintainer of such a library I think it's your duty to refrain from adding every requested feature. If your users need more flexibility then break down y

As the maintainer of such a library I think it's your duty to refrain from adding every requested feature. If your users need more flexibility then break down your library into building blocks that will allow them to build exactly what they need by composition. Reusable code isn't generic, reusable code is focused and built out of (re)composable parts. Reusability IS composability.

jrochkind1 12y ago
I have had the experience where I _think_ I (or a distributed open source team on a project I commit to) am doing what you suggest -- but then retrospectively, I see it still resulted in too much complexity through over abstraction/engineering. I think you've got the right idea, but it still doesn't always make it easy. The places I have found the most success in my design, even looking back, are when I constructed a library for a domain I was already well familiar with (often having experienced how another library handled it), and where I had the time to do it slowly and carefully, deliberately considering each design choice and the simplest possible way to achieve each desired path while still allowing for flexible reconfiguration. When working with other developers, this often, as well, involves some initial disagreement about the best solution that accomplishes without adding unneeded complexity. And sometimes even I start getting impatient with the slowness of the deliberate process and consensus building -- it's easier to do by myself (which takes even more time). These are rare circumstances that allow for such slow coding though, in the pressure to get things out quick and get them used and then quickly iterate. We have a (hard-won, reaction to other harmful development ideologies) overall ethos in our industry(ies) of getting things out quickly without needing to get them perfect or fully understand where it will lead you, and then iterate based on feedback. That works pretty well for UI, although it can still contain the same pitfalls. It is even harder for infrastructural architecture though, it's probably still possible as long as you are careful and deliberate with your iterations (although knowing when to break backwards compat is still a trick), but, anyway, I don't think it's easy.
- thibauts 12y ago
  I completely share your experience. It almost always takes me two complete drafts before getting an architecture right anyway. This probably looks awful to people who like to "ship" more than they like to "build". I like to build. Converging towards the simplest representation of a problem's solution takes a strong ability to let loose on your mental pictures in order to escape local maxima, and time. What we do is essentially rewiring our brains around a problem. In this respect we are bound by biological processes. There is no shortcut. Every path that looks like a shortcut will lead to conceptual pollution that will only grow like the square of the team size and seed what we use to call technical debt.
  - jrochkind1 12y ago
    Yes, you said it well. It requires a very thorough understanding of the domain you are working to create a solution in. And time and effort. The actual context most software engineers find themselves in does not usually encourage (or even allow?) that kind of development. Creating quality software really is more 'expensive'.
    - thibauts 12y ago
      Yes it tends to be more expensive at first. But look, as a community we can't even (yet) agree on what makes quality. It is hard to sell something you can't clearly explain.

jrochkind1 12y ago

I have had the experience where I _think_ I (or a distributed open source team on a project I commit to) am doing what you suggest -- but then retrospectively, I see it still resulted in too much complexity through over abstraction/engineering. I think you've got the right idea, but it still doesn't always make it easy. The places I have found the most success in my design, even looking back, are when I constructed a library for a domain I was already well familiar with (often having experienced how another library handled it), and where I had the time to do it slowly and carefully, deliberately considering each design choice and the simplest possible way to achieve each desired path while still allowing for flexible reconfiguration. When working with other developers, this often, as well, involves some initial disagreement about the best solution that accomplishes without adding unneeded complexity. And sometimes even I start getting impatient with the slowness of the deliberate process and consensus building -- it's easier to do by myself (which takes even more time). These are rare circumstances that allow for such slow coding though, in the pressure to get things out quick and get them used and then quickly iterate. We have a (hard-won, reaction to other harmful development ideologies) overall ethos in our industry(ies) of getting things out quickly without needing to get them perfect or fully understand where it will lead you, and then iterate based on feedback. That works pretty well for UI, although it can still contain the same pitfalls. It is even harder for infrastructural architecture though, it's probably still possible as long as you are careful and deliberate with your iterations (although knowing when to break backwards compat is still a trick), but, anyway, I don't think it's easy.

thibauts 12y ago
I completely share your experience. It almost always takes me two complete drafts before getting an architecture right anyway. This probably looks awful to people who like to "ship" more than they like to "build". I like to build. Converging towards the simplest representation of a problem's solution takes a strong ability to let loose on your mental pictures in order to escape local maxima, and time. What we do is essentially rewiring our brains around a problem. In this respect we are bound by biological processes. There is no shortcut. Every path that looks like a shortcut will lead to conceptual pollution that will only grow like the square of the team size and seed what we use to call technical debt.
- jrochkind1 12y ago
  Yes, you said it well. It requires a very thorough understanding of the domain you are working to create a solution in. And time and effort. The actual context most software engineers find themselves in does not usually encourage (or even allow?) that kind of development. Creating quality software really is more 'expensive'.
  - thibauts 12y ago
    Yes it tends to be more expensive at first. But look, as a community we can't even (yet) agree on what makes quality. It is hard to sell something you can't clearly explain.