So four developers and two psychologists walk into a bar...

One evening at our usual beer meetup, we thought about some weird social experiments, somehow related to software development and developers life, that we want to try. Then, back from Goto;Aarhus Fulvio was talking about the conference with a psychologist friend and somehow the topic shifted to gestalt, then to the experiments we thought of. And he was enthusiast to hear about that.

So in the optic of building a cross-functional team Maria and Andrea joined us in this project. A few weeks later we arranged a meetup between developers and psychologists to mix viewpoints, experiences, knowledge, some beer and create (we hope) something new, interesting and exciting.

Codeblots

We wanted to find a way to start a discussion without putting some bias in it from the start. Why? One of the possible use cases is during a job interview, to understand which kind of approach a person has without forcing the conversation. We saw a similarity with the Rorschach test, and decided to try inventing an analogous test using code fragments instead of inkblots. So this is the idea with we started the meetup, and everyone got enthusiast with it.

After stating the goal we tried to learn something from our reciprocal fields, so we had a little chat about how and why we (developers) had these ideas and what they (psychologists) thought about it, taking the chance to learn and explain our viewpoints and values through examples and metaphors. When everyone got used to some basic ideas and terminology we started deepening our knowlege of the Rorschach test. Luckily Maria is currently studying exactly that test so she explained everyone how it works and which principles it's built upon. In particular we were curious about what information we could get by administer the test and which resources are needed to build it. We learned that after running the test, in order to get the results, the test subject's asnwers are given a set of scores, then checked against tables built from clinical data.

So in order to build properly this new test we need data first. But the objective of starting an unbiased conversation using code fragments is met even if it's not properly a test, hence we decided to begin using this tecnique "as is", and in the meantime gather data for a future evolution.

That was it for the meeting. We left with a target for the next time: start to build the basis for the experiment. We have still no idea about how to properly build an "item" for the test (that is, in our case, a code snippet) so the homework for the next meetup is to build some samples to administer against each other in presence of Maria and Andrea, so that they can evaluate which building principles seems effective and which not.

It's not a storage shelf

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.

Bookbuckets

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).

Details of the general

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).

LookAhead

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.