DEV Community

Discussion on: The biggest mistake library and framework maintainers make

Collapse
 
thatjoemoore profile image
Joseph Moore

I either maintain or contribute to multiple internal libraries and tools, and I have to say, this is a lot harder than many might think. I'll spend weeks hounding developers for feedback on something, and won't hear anything from them until months later, when that decision is now irrevocably baked into the library.

I don't think that this problem is anyone's fault, but it has shown me that it IS something you have to account for in your planning. As the project maintainer, you have to assume that real developers aren't going to drop everything to give you feedback, you have to get creative in finding ways to encourage them to give feedback. For example, I was working on a library that was going to affect my team and several others, so I ended up going to our director and convincing him to give me a few hours of people's time every week to play with and five feedback on this library. They had always been free to spend that time on things like this (we have several hours a week set aside to things like this, or to professional development), but by having someone in authority grant explicit permission, people felt like it was a priority. I've also seen other developers schedule actual meetings to talk about what they've been working on and solicit feedback on the design choices they've made.

Those techniques have been helpful within my organization, but they don't exactly scale to a large open-source project. You can't just drop a meeting invite onto 10,000 people's calendars! I think that's why a lot of projects issue prereleases, release candidates, feature previews, etc., and then encourage people to try them out and give feedback.

One potential problem with this is that the only people who will carve time out of shipping the next feature on the backlog to test your library are the hard-core users - the ones who know your library inside and out, and who have already learned and come to believe in your projects philosophy. They're often not the run-of-the-mill developers whose lives you're trying to improve.

I think this is why a lot of projects also engage in dogfooding. I personally find a lot of issues when I go write a real app with the tools I work on (which is actually my main job anyway!). Many projects engage in this, but there are pitfalls here too. For example, if your dogfooders aren't a representative sample of your developer population, you're not going to get the kind of feedback you could otherwise. Take the observation about React that started this discussion: I wouldn't be surprised if that problem is a result of the fact that React was originally developed by and for Facebook, and is largely dogfooded there. Facebook is pretty different from most apps in that their state-management problem is vastly more complex than their data-loading problem. So, naturally, the original design and the focus of their thinking and testing is focused around the very hard problem of state management in Facebook-like app. From what I've seen, they do a good job of getting feedback from other developers, but the loudest voices in their ear are often going to be their internal developers.

This whole feedback-from-developers thing can also be pretty hard because of the inevitable backlash that comes when you have to disregard one use case in order to make the rest of them better - I had one project where one developer was very angry because we wouldn't rewrite the core of our project in order to accommodate some of their self-imposed challenges, and how it meant that we didn't care what anybody's needs were and that we were developing in a vacuum and that our year's worth of effort was wasted. We knew from the rest of our feedback that our library worked well for the 95% use case, and their use case was in the other 5%, so we were able to shake it off. We still tried to find ways to help that developer, but we weren't about to make life harder for everyone else just for them!

All of this to say: I don't know how to solve this universally. Projects need to work really, really hard to get feedback from real-world developers, and developers need to somehow find the time to pay attention to and five quality feedback on changes to their tools. Both of these are hard, and there's no silver bullet that can make them easy, but it's certainly a goal worth striving for. Hopefully those projects that do it well can share their secret sauce with the rest of us 😀.