Originally, I come from a .NET world. I love programming C#. I love the language, the typesystem, but I eventually left it a while ago, due to the lack of opensourceness. This was back when Ballmer was ranting something about developers. Thank god, for Satya Nadella who is pushing MST back on track. The main reason at time was that I felt that the open source and especially Ruby/Rails, gave me much more productivity and was mapping the issues I was running into much closer to the real world.

One of the things I discovered, when i started untangling my feels, was that the frameworks in the Ruby/Rails world were extractions.

Meaning that, instead of some monkey thinking that feature x was needed or was going to be a problem or needed extending in the future, this framework was written because someone else actually had duplicated their code already in a ton of projects.

I drew an important lesson out of this:

  • Don’t extract common logic until it hurts. This is pretty much YAGNI.
  • Keep duplicating your logic a couple of times across different projects until you really understand the core of the problem that you want to write an abstraction for. After a couple of implementations you willl start seeing the gist of your issue, enabling you to extract the common denominators into a package or library.

Personally, I apply this to everything. I almost never design upfront. I try to build software with minimal lines of code to ensure refactoring is easy and straightforward. I never ‘future proof’ unless i need it now. This idea also resonates in the Is Design Dead? article written by Martin Fowler.

Another thing where this comes to play is with the GraphQL RFCs procedure. While attending GraphQL Europe, Lee Byron explained the process of accepting GraphQL RFCs to the audience.

He told the audience that he wanted to keep GraphQL as pure as possible. And if you wanted to add something to the GraphQL spec, you first need to use the proposed feature yourself, hacking around the GraphQL spec, and see how uncomfortable it is. Use it a couple of times and then propose a feature, when you (and others) clearly see the benefit of it.

So long story short, feel the pain, a lot, before abstracting. It will save you some headache.

And ultimately don’t impose some sort of holy extendable framework upon others until you’ve actually used it yourself in production you jerk. I’m looking at you Enterprise Library.