Beware False Idols

In my search for a new role I met a great recruiter. Seriously, she's awesome and I can't recommend her highly enough. After I'd met with her client she sent me a list of 4 questions asking for some insights into the industry. So, I had a few beers, settled in, and let fly.

One of these is below.

Q: What other trends are you seeing in your space?

A: The seemingly exponential growth of the amount trend chasers in our industry.

For example, the amount of people that claim to love "functional programming" but have no way to actually define it. Much like Ruby on Rails was a hot term, and then NodeJS was a hot term, and ReactJS is a hot term now with its functional components; I am seeing a massive bandwagon effect of people with no fucking idea what they are talking about espousing the beauty of X whilst fucking it up. This has massively deleterious effects on industry progress, as the right thing done the wrong way makes the non-technical folks distrust it (and rightly so).

It may have always been like this and perhaps I'm just old enough now to see it, but anyone that has buzzword soup on their resume or linkedin profile I think needs a thorough vetting because they're probably full of shit.

So this got me thinking about the proliferation of terrible ideas in our industry. We have all these concepts emerge and then, like the-little-mushrooms-that-could sprouting on a pile of cowshit; an army of experts in the thing emerge. Have you ever noticed that not a single shred of evidence is ever asked for nor provided that the thing is actually good. Even more so, the thing is spoken of with such fervent passion it's if this speaker has been touched by god and we must now become disciples of the One True Way.

So with our new found skepticism of panaceas, lets go adventuring dear reader.

Liskov Substitution Princple

The L in SOLID. This thing has a Wikipedia article. It has super fancy phrases like "...[is] an extension of Hoare logic" and it even introduces the "notion of substitutability", amongst others. Hell, it has its own interesting algebra! It's part of an acronym! It must be good right? Well, heres the thing - it doesn't mean anything. There is not a single shred of useful mathematical proof that can be derived from this. There is not a single piece of engineering wisdom that can be gleaned by following this idea.

Lets demonstrate this, right now, using some python inspired psuedo code.

class DatabaseConnector:

    abstract connect():
        raise NotImplementedError

    query_db(query: StandardsBasedQueryObject):
        return this.connection.query(query)

    close_connection(close: StandardsBasedTerminatingObject):
        return this.connection.close(query)


class RedisDatabaseConnector:

    override connect(**params):
        return redis.connect(**params)


class PostgresDatabaseConnector:

    override connect(**params):
        sql_connection_string = sql_conn_generator(**params)
        return postgres.connect(sql_connection_string)

Here we have a DatabaseConnector class with a single abstract connect method. Abstract methods and classes are useful. I can't mathematically prove its useful, but after doing this for the better part of 15 years I definitely find them useful. They're a kind of "super interface" - letting us add state mutating members to the instance but still allowing us to specialise the class.

Using our super-interface abstract class, with a few lines of code we have specialised out a Connector to both Redis and Postgres. And now by the magic of inheritence and the power of subtyping we can do this and the compiler wont whinge:

class StartUp
    static connect_to_db(connector: DatabaseConnector):
        return connector.connect()

StartUp.connect_to_db(RedisDatabaseConnector())      <---- works!
StartUp.connect_to_db(PostgresDatabaseConnector())   <---- works!

How awesome is this. No repeated code. Compiler-checked types. Psudeo-generic types via hierarchies allowing arbitrary database connections. Seems good to me. Seems good to you. Seems good to the PR reviewer. But I've just broken the Liskov principle. SOLID is now SOID. Our systems will crash. The (big)ender-dragon will consume the souls of children on the bitscape.

Why is this bad?

Don't know.

Well, we do know actually.

You see, we can't sub out Postgres for Redis. And according Liskov this is bad. All supertypes should be able to swap in for their subtypes. This must mean they are also commutative. The principle is broken. And this is bad. But Why?

This time I actually don't know. Lets ask a different questions: Why is this principle good? Why should I follow it? What benefit does it convey? Its a guideline. An opinion. It's assumed to be a good idea, but it is never explained why. It is a best practice that, by her own words, holds no intellectual weight nor engineering significance nor mathematical guarantee.

To wit:

In an interview in 2016, Liskov herself explains that what she presented in her keynote address was an "informal rule", that Jeannette Wing later proposed that they "try to figure out precisely what this means".

"Informal rule". No basis. Nothing. Nada. Zilch. Literally no concrete meaning. Still trying to decide "precisely what this means."

Heres the thing though - I actually don't give a shit about this. Liskov is infinitely smarter than me, and her opinion is undoubtedly more important than mine. Here is what I DO have a problem with.

Give. Me. A. Fucking. Break.

These experts, these exhaulted leaders of thinking and engineering and creation... they're all on the same bandwagon without a single thought as to what this means in practice. Do you know what the worst thing is though? They teach this shit in university.

Never, ever, ever in my career have I ever cared about making sure I can transparently swap a subtype instance into its super type. I sure as hell have liked using abstract templates in the form of classes with overridden methods though.

Lets go back and ask the arbiters of truth about any other potential benefits. According to the Wikipedia entry, based on expert opinion, one advantage of the Liskov Principle despite its informal specification and lack of formal it proof that it...

Nonetheless, the principle is useful in reasoning about the design of class hierarchies.

Is it though? Your mileage may vary. Mine sure does.

"But Jamie, you impertinent rascal", you exasperate; "you're merely picking on your pet hate".

Oh please. I'm picking on our industry. Why do we do this? Why do we mandate things that sound good with such vigour, why do we write it into our education and into our job checklists and into our core systems and platforms and into our architectural reviews. Why is it for a profession that claims to be the ultimate practical manifestation of logic we can't prove a damn thing we yell as matter of fact. And worst of all, why do we elect tHoUgHt lEaDeRs who can prove nothing and do naught but preach the opinions of others with not a shred of credibility behind their name.

Fuck these people.

We all need to git gud.

---

Full question list