I like books.
Every once in a while, I spend an entire day rearranging my library. Moving, categorizing and sorting all the books and manga I have in it.
Deciding when and how to place them one next to the other. By topic, by color, by shape.
Deciding which book to keep and which to put away into the "this is not worth" box.
But why bother? I have some books and the library's shelves are a place to put them. Just stuff them in, and gg.
Well, for me that's just unacceptable.
I want to look at my library and say proudly: "Neat, huh?".
So, I wanted to talk about why it's the same for a code library.
There are small, essential libraries that do one thing. And that's ok. SRP is good.
But then you dig deeper into its presentation, read something like "OMFG IT'S SOOOOO EASY TO USE, YOU ONLY HAVE TO CALL ONE LINE!!11! MYLIB.DOSTUFF() AND YOU AM DONE!!!11one!" and it starts to smell.
And then you try to use it for something that looks "just a few lines of code away from what the library already does", only to discover that to configure or extend any behavior it's required to sacrifice a black rooster in a full moon's night.
Or there are other libraries, that you include to use a single, specific feature that's useful. And for that single class or function you include 20MB of library, which contains not only stuff you'll never care about, but stuff that has really nothing to do with the rest of the library itself. Libraries with just an enormous lack of coherence.
That's the feeling that a "bookbucket" gives. The feeling that someone wrote some shitty code, looked at it, said "OMFG I'm such a genius! Let's inflict my incompetence and bad taste to the whole world!!1one!", copy-puked everything in some random files and then published it along with some catchy phrase on a social network.
(I'm exaggerating it here, just let me be).
So, what's different in a "real" library?
It's not the extendibility or flexibility. We have some small libraries that offer features not extendible at all. Like, one for embedded servlet containers that only offers a tomcat preconfigured to serve JSON messages over RESTful endpoints. Why that's ok? Because that class is called EmbeddedRestfulJsonTomcat, not EmbeddedTomcat. It does a specific thing, not anything you want, and we made it clear.
It's not the dimension or the quantity of different stuff you could find inside, either. Take dysfunctional: 80% of the time what we use of that library are only Delegates, map() and Maybes, yet we are forced to also get Ranges, Eithers, Boxes, Spies and a whole bunch of Iterators. And we're fine with that. That's because even if some features don't look related at a first glance, the library is actually coherent: complex abstractions are built on top of smaller ones always mantaining the library's vision, there's nothing inside that results redundant or in excess. And starting with only the most common parts, as the complexity of the the software relying on that increases, it's only natural to arrive at a point where the least used functions acquire importance and usefulness.
That's a focal point when building a good library: honest Contracts and polished Abstractions (And yes, in the Tomcat example for honest contract I mean the class name).
I'll tell another story: everytime someone wants to add something to dysfunctional, he always asks rferranti, who's also the repo owner, first. It's not a request of permission, but rather a confirmation: "Do you think that's a good idea too, or did I forget about something that makes it a poor choice?". Well, actually we always consult at least two other people too, to refine the idea and take confidence in it.
What I mean is that the big difference is the care for what you're building. And care in building your libraries means care in building your future.