Why would I NOT use my own framework and how I sell usage of Symfony2 and other current PHP 5.3+ goodies to my client

Tags

Sometimes, in a mailing list I am following and in real life. People are sometimes explaining their choices in technology to create an e-commerce site using a CMS ("Content Management system") or their own "homemade" framework. As if there is no good PHP ones out there nowadays.

A CMS is a web application to manage content and when specialized requirements (as in managing other things than pages of content) we have to extend outside of the CMS part. A framework is thus a good friend.

In either case. My opinion is to use the right tool for the right task.

I wrote on the subject because I recently had to defend my technological choice of Symfony2 at my (very-large) client. You can see on these two posts.

I tend to believe that everybody who can program can work with a well architectured CMS/framework whatever software architecture patterns it is following. The priority is that we, programmer, fills the client's requirements and use what is existing to make us efficient.

Creating a "just for this project"-"super custom"-framework and saying it is using [a buzzword-compliant] architecture principle, doesn't PROVE IT well made.

Don't get me wrong. It is not that creating a framework is bad. It is quite an educative hobby. Creating a framework requires a lot of work, dedication and ideally a quantity of skilled people to work to improve, review, test and document. A full time job by itself alone.

My feeling is that the client probably did not asked to create a "framework".

My problem is more precisely about using it as production-code for their business application, make them pay for it AND what they explicitly asked for. Should they only pay for the features they asked for?

But if you used a well known, documented, framework with an active community. You can use it as a good selling argument in front of the client. It even reassures them that other people can take on your work.

So a question lingers in my mind. If one has the skillset to create his own framework. Why doesn't he contribute to an existing one?

Personally, all my choices follows the NIH approach. NIH as in "not invented here" see Derek Strobe's blog post about NIH, a much inspiring read.

The overall idea is that Instead of charging for my time implementing dependency injection, i'll use an existing one.

Maturity

Talking about maturity. Symfony2 is 2 years old already (compared to Zf2 few month of age).

If it is not only about maturity. Think that the PSR (levels 0, 1, 2)  recommendation is written by a group community leaders who decided to standardize the way to structure libraries so they are inter-operable, PHP FIG was created for this.

I think everything changed since the PHP-FIG group created the PSR* standard and the use of composer to manage dependencies. CMS and other framework projects have to follow the lead, otherwise they may get left behind.

CMSes

I have the feeling that someday CMS will be only a GUI, with full edition capability (see Mercury Editor, or Createjs) using HTML5's  ContentEditable property. And persisting inside a Storage engine known as "Content Repository".

This trend is also what some calls "Decoupled Content Management" (also explained here), a VERY promising concept that will give some more chances for us to actually re-use code.

The prospect may even make us be able to really create easily semantic-friendly pages. Created by editors. Regarding semantic web, you should look at "VIE" over here.

The trend is more than mere theory. Many project spawned already. Most notably the Symfony-CMF, Midgard and even known CMS-es such as Drupal and Joomla are currently re-evaluating their projects and following the trend.

Dependencies

A common problem is how can I make sure the project uses proper libraries and a compatible version number.

Many stacks has their own implementations of it. It comes as a simple file stating which version you want, and it takes care of getting the proper version from any configured package we may think of.

The concept is now new and many web development stack has their own implementations. Have a look at package.json (for Javascript), Bundler (for Ruby).

PHP has it's own now, it's called Composer, here is how you would declare your dependencies:

{
   "require": {
       "myown/vendor": "master",
       "external/lib": "3.1.*",
       "external2/template": "master"
   }
 }

See: Introduction to composer using Packagist

Add to that any cache management, deployment configuration and other build libraries, compilation and protection you may wish to use.

All in all

Nowadays. If you are still:
  • Manually using require_once(...)
  • Adding database queries in your view (WordPress? x_X)
  • Using loops and query hidden in a ... templating engine (ExpressionEngine "loops" x_X)
You may need to see the reference I made in this post.

My argument goes as following, mostly for what my (our) clients pays us for:

  • Learn and make good use of framework that has a reputation, good architecture, modular, inter-operable with other, in PHP is not a chimera anymore.
  • NIH please
  • Build functionality for the client who pays you. not maintain the serializer service mechanism... framework do that stuff. client do not care about it
  • SOLID principles?
  • Scaling? (only one database? what if I need to go deploy on a PaaS solution?)