Publish Your Failures; or, The Way Of All Frameworks

By | October 28, 2013

The blog post Is ORM Abstraction A Pipe Dream? is one of the best technical articles I’ve read in maybe a year. Not because it describes a successful technical solution, but because it describes an attempt and a failure to achieve a goal. It reminds me of this quote from Feynman in Cargo Cult Science:

If you’ve made up your mind to test a theory, or you want to explain some
idea, you should always decide to publish it whichever way it comes out.
If we only publish results of a certain kind, we can make the argument
look good. We must publish both kinds of results.

(Cargo Cult Science is one of those essays that everyone should read, especially programmers who think of themselves as scientists or science-minded.)

What Feynman is saying here is that, when it comes to expanding a body of knowledge, the failures are just as important as the successes, perhaps more so in some cases. (Be careful here; they have to be “honest” failures, where you had some reason to believe in advance that it had a good chance of working.)

So what is it about the “Pipe Dream” article that impressed me? It is that the the author first signals his tribe membership by mentioning his “framework of choice”, then proceeds to try to do some work outside of that tribe. In doing so, he is expanding his knowledge and skills so that he can be useful outside the norms of that particular tribe. He realizes that there are other ways to do things than the way his tribe does them, he does some work with those things, he tries to unify them, and he fails at the unification. In the end, he has no technical artifact to show for his exploratory work, but he has now expanded his skills as a programmer beyond his “framework of choice.”

Your Framework Will Fail You

And being able to operate outside a framework is really important, because the framework you choose today, even if it’s the self-described “greatest PHP framework of all time”, is going to fail you in some non-trivial way in 3 years or so, even if it has a “long-term support” version. (After all, how long is long-term in the web world?)

Take a look at some points from this article by Yannick Mahe titled The consequences of living with a legacy PHP framework (note that “legacy” in this case is only 4-5 years):

You can no longer rely on the community. …

Documentation can be hard to find now. …

I can effectively no longer use plugins. …

[This framework] used Prototype (scriptaculous) as its Javascript framework … UX advances which could require just a simple jQuery plugin have to be written from scratch. …

This framework is not compatible with newer versions of PHP. It was written for PHP 5.2, and is compatible with PHP 5.3 but no longer works on PHP 5.4. …

Basically I’m one third less productive when programming than I could be.

Is that a slam against the framework or its defenders? No more than saying “the sky is blue” is a slam against the physics of light diffusion in atmosphere. “The framework is going to fail you” is a truism regardless of the framework.

And everybody uses a framework, whether they recognize it or not. I have said at other times that a “framework” can be defined as “that collection of tools and techniques you reuse on a regular basis from project to project”. So everyone uses a framework one way or another, whether formal or informal, well-architected or not, designed with intent or evolved through use.

How To Handle Failure

So if all frameworks are going to fail you, and you can’t avoid using one, what are your options?

All too often, software is like a complex system in that requires a constant input of energy, and complex systems fail. So the key point here is not “the framework is going to fail you.” The key point is “how easy will it be to handle that failure when it happens?”

A developer twin of Nassim Taleb might argue that whatever framework you have needs to be antifragile. That is, when one subsystem fails or becomes obsolete, it should not render the rest of the system unusable. Indeed, the failure of a subsystem should lead to a replacement that makes the system stronger in the future.

Frameworks in general are especially susceptible to their subsystem failures: they are usually developed as a thing of whole cloth (yes, even the ones that advertise they are “component based” — the components might be OK, but the framework often is not). The different parts depend on each other, and if one fails, you need to dive into the guts of the framework proper to fix it in place, which frequently leaves you worse off than before when it comes to maintainability.

Instead, for a robust or antifragile system, you should be able to swap out the different subsystems when they no longer meet your needs. As each piece fails (and each one will eventually fail to meet your needs), you’ll swap out each of the pieces at different times. Eventually the system will be composed entirely of replacements, but the whole thing will have kept running the whole time.

And that’s where we come back to the “Pipe Dream” article. By taking some steps outside his “framework of choice” the author is beginning to get an idea of how to integrate independent and disparate systems into a whole. In the long run, that ability is going to serve him better as a programmer than his knowledge of any particular framework.

Afterword: Aura for PHP

Of course, I’m going to mention Aura here. The ideals illuminated by article are the ideals that drive the development of the Aura, even to the point of prejudicially declining certain feature requests.

The Aura project is a collection of truly independent and fully decoupled libraries. None of the libraries has any external dependencies. The project is “library-first” and not “framework-first”, even though we do offer a framework built of the combined packages. The libraries evolve independently of the framework and can be incorporated individually or in any combination you like into any project.

If you liked the ideas behind this article, then the Aura project is for you. Download a single package and start using it in your project today, with no added dependencies.


UPDATE (30 Oct 2013): The title on the final section has been prefixed with the indicator “Afterword” since at least one person mistook it for a summary.

58 thoughts on “Publish Your Failures; or, The Way Of All Frameworks

  1. taylorotwell

    I don’t buy it. This blog post comes across like “don’t bind yourself to a framework. Oh wait, it’s ok to bind yourself to Aura because some how you aren’t really binding yourself to it”. Just because Aura components are de-couped amongst themselves doesn’t change the fact that an application that uses them *is* coupled to Aura.

    For example, if I want to truly de-couple myself from a library or framework’s query builder, I would need to define a SqlProviderInterface (for example) in my application, then write an AuraSqlProvider implementation that gives me some abstraction to code against instead of a hard, concrete dependency on Aura. And, then I can write a LaravelSqlProvider, DoctrineDbalSqlProvider, etc. and switch between them. But acting like just using Aura automatically gives you some future-proof de-coupled heaven is misrepresenting reality a tad in my opinion.

    Reply
    1. pmjones Post author

      As the author of “the greatest PHP framework ever” I’m not surprised that you don’t buy it. That you think the phrase “you can’t avoid using a framework” comes across as “don’t bind yourself to a framework” helps to Illuminate that.

      Reply
  2. taylorotwell

    None of what you said addresses my point that using like Aura.Sql *is* coupling your application to Aura, unless you put an abstraction (interface) between you and Aura, my usage of Aura is no “more” de-couple than just using Doctrine or Illuminate/Query.

    Reply
  3. taylorotwell

    Whatever, Paul. The implication of the article is that Aura somehow protects your application against the failure of “your framework”. But Aura can fail too, and unless I am putting an abstraction layer between me and *any* outside dependency, including any framework, Aura, etc. my application will fail. Aura is not special in that regard. Again, just because you take pride in the fact that Aura’s components are not coupled amongst themselves, that changes nothing about the fact that any application that uses Aura IS coupled to Aura. That’s what “you’re not getting”. Maybe read that with a fresh set of eyes tomorrow.

    And, if I have to go that point of putting that abstraction layer in (which I should if I’m aiming for that level of purity and separation from my underlying framework), Aura is not different from any other library or framework that ships their parts as components. Doctrine DBAL, IlluminateQuery, and Aura.Sql are all on the same footing there, so it’s disingenuous to act otherwise and then take some smartass stance that I don’t “get it”.

    Reply
  4. morrisonlevi

    You have this great article that you diminish by including the shoutout to Aura. Even if Aura really is great it will still eventually fail — the very point of your otherwise excellent article.

    Reply
  5. Lukas

    @taylorotwell I think Paul’s point was that as they are decoupled, one can replace each component one by one. But I agree with you that this is selling another pipe dream because as you rightly point out, then all the coupling will happen inside your own code (or in the “framework” that aura also seems to provide). Furthermore Paul insists that having optional dependencies provided by components makes them coupled, while Aura simply moves such optional coupling to their framework components or the end users code.

    So the gist of it for me, yes frameworks fail, yes managing dependencies and coupling is important when needing to deal with this, so its wise to plan ahead. And no there is nothing that makes Aura by design less or more problematic than several other alternatives like Symfony2 and ZF2 ..

    Reply
  6. Amy Stephen

    Right now, there are a dozen, or so, PHP devs who I pay close attention to as their approach embraces quality, industry standards, collaboration, open architectures.
    Paul is one – it is truly impressive what he has achieved with the concept of decoupling in Aura. It’s not easy, if you’ve tried it, to separate software that cleanly.
    A second is Taylor. In Laravel, he has balanced software architecture with the need for developer productivity. He’s done so in a way that it is part of the architecture to easily add new packages from other environments.
    A third is Crell. He understands the need for an open, pattern-based architecture for Drupal 8 and he believed in the value of open source in adopting Symfony2.
    It is true — our frameworks will fail us. But, when built right, the failure can be isolated and systems built with component parts will be better positioned for the eventuality Paul so accurately describes.

    Reply
    1. pmjones Post author

      That’s what I’ve been saying; thanks for backing me up. Maybe he’ll get it eventually.

      Reply
  7. ngregory

    laravel/laravel has 6,600+ github stars

    auraphp/system has 62 github stars

    I find that Illuminating

    Reply
    1. pmjones Post author

      It could have ten million and Aura (among all its components) could have zero — Taylor still missed the point in his opening comment.

      Reply
  8. Pingback: "Don't Bind Yourself To A Framework": or, Shut Up and Build Your Shit - Steven Wade

  9. Matthieu

    Dude, that comment was addressed to you. You seriously need to open up your mind.

    Reply
    1. pmjones Post author

      Oh, you mean that its possible for people to completely misunderstand what you consider to be a clear and obvious meaning? I’ll keep that in mind; thanks!

      Reply
  10. Ross K.

    Thanks for pointing the way to all this cool stuff, Paul. It’s easy to miss good information with all the so-so info in the way. Propers.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *