To framework or not to framework?

Posted on 10.11.2015 by Kim N. Lesmer.
What level of complexity to you want to be at? Are you really thinking about and understanding what you're doing or are you just following "trends" and always using a framework?!

Software development should be all about understanding technology and not about following "trends", but that's not the way things are any longer.

If you are a software developer do yourself a great favor and read the following books - if you haven't:

The Pragmatic Programmer: From Journeyman to Master

Refactoring: Improving the Design of Existing Code

Clean Code: A Handbook of Agile Software Craftsmanship

These books are some of the best books about software development. They are not about following trends, they are all about understanding what you're doing, and they should be obligatory reading for any programmer.

Concepts, religion, and principles

Even concepts as fundamental as elimination of code duplication (DRY), code expressiveness, and the sinle responsibility principle (SRP) can be taken too far.

In an effort to make our classes and methods small (when working with the object oriented paradigm), we might create to many tiny classes and methods.

All experience starts with the interface. The interface experience is the result of the underlying technology and the amount of layers of abstraction. The more abstraction you use, the less efficient the interface becomes and the more error prone the application becomes.

The higher abstraction, the more detail and efficiency, is lost.

Every rule has it's exceptions. Don't be fanatical or religous about following rules except one rule: Keep It Simple, Stupid (KISS).

The more abstraction you use, the more difficult it becomes to maintain and change code. If you make things really simple by having less code, you can change code as easy as hitting the DELETE button! It also becomes much easier to write documentation because you have less code to document.

In the PHP community a really bad trend has become de-facto for developing web applications and that is by the usage of a popular general purpose framework.

This trend has not emerged and become popular because it in any way improve the result of the developing process, or because it is the right thing to do from a technology and architectural point of view. This trend has become popular because some of the developers of frameworks has managed to sweep away the masses with their polemic against programming from the ground up with stanzas like, "Don't re-invent the wheel!" and "Don't do it yourself, others are more skilled than you".

The fact of the matter is that these framework fanatics has been caught up in feelings of self-importance and self-glorification because of the thrill of having other people use their projects.

All general purpose PHP frameworks suck. They all produce inefficient clutter, they do not improve the resulting software in any way, and they work against the whole purpose of the underlying HTTP technology.

Understand this: The ideal number of lines of code in any project is as few as possible!

Systems-built homes that are pre-constructed in a factory before being transported to the home site to be completed are among the fastest-growing segments of the residential construction industry, but that doesn't mean they enable you to call yourself a carpenter just because you assembled such a pre-built house. In the software industry you can compare a pre-built house to a framework or a library. Building software using frameworks doesn't make you a coder or a programmer any more than putting together a pre-built house makes you a carpenter.

When I started coding in PHP everyone was developing PHP applications either from the ground up or by reusing their code as small libraries in different projects. Then came along some people who thought it was clever to not only have libraries, but to have frameworks. They developed software that would generate software and they then tried to make them "general purpose solutions", or "one size fits all" solutions. The word "framework" quickly became a buzzword and as with all buzzwords religious groups of fanatics started telling everyone that it was wrong to code from the ground up and you should really use their general purpose framework (or at least some framework) to make your software.

A lot of companies started their next hot project using one of these popular general purpose frameworks only to end up in a disaster. They not only discovered that the general purpose framework was really bad at solving their specific need, but it was also extremely slow in doing so. It was impossible to scale and as a result they started ripping the framework apart in a desperate attempt to pull out all those things they really didn't need.

But that didn't solve the problem, the problem only grew because now they where stuck with a nightmare to maintain and no one dared touch it with a barge pole because even minor changes could make the whole thing break.

A lot of those companies eventually came to their senses and hired some real programmers to develop fast and scalable custom made applications from the ground up - which really was (and still is) the main purpose of PHP to begin with.

Rasmus Lerdorf, the original developer of PHP, developed PHP using the C programming language, and PHP was essentially "just" a parser. PHP has since then grown and become a general purpose programming language and lots of features has been added, but PHP essentially still is a parser ment to make it really easy for people to develop web applications.

In the world of Python there is a saying that goes:

There should be one - and preferably only one - obvious way to do it.

PHP supports imperative, functional, object-oriented, procedural, and reflective paradigms. PHP is a huge toolbox with lots of different tools that makes it possible to solve many problems in many different ways - not just one way.

Some people state that this is a weakness of PHP, but in reality this is one of the strengths of PHP.

I have a friend who is an entrepreneur. Besides being really good at startups, he knows how to install Wordpress or Prestashop and he even knows a little about how to make applications talk to each other using an API, but he is not a programmer.

When he has got a new idea for a startup he quickly puts together some solution using a framework or a general purpose application targeted at that task, he then installs Wordpress to create a blog or website for the startup and he installs severals Wordpress plug-ins in order to make easy usage of affiliates, Facebook, and Twitter.

Next he calls a graphics designer to create some graphics and within very few days he's already in business, contacting other companies, creating value and doing all the practical stuff to get the startup going successfully.

At some point in time his startup out-grows his initial setup. Now it's no longer a startup but a successful company with a working staff.

The company now has some very specific needs that cannot be fulfilled using his original setup with a general purpose application. The company needs a very specific application and that application needs to be really fast and very scalable.

My startup friend knows how to deal with such a problem, he hires a real programmer, or several, to develop that specific application from the ground up.

The point of this example is the well known phrase: Use the right tool for the job!

PHP is all about freedom, fast and scalable solutions, and having many different ways to deal with problems. It's not about doing everything just one way.

Rules, regulations, restrictions, and guidelines are great when limited to a specific company or a specific project within a very specific task. Such regulations makes it possible for people to cooperate more efficiently in that particular project. But trying to jam such rules and regulations down the throat of everyone else not only limits people, it limits creativity, it limits efficiency, and in the long run it is even costly financially speaking.

So you could solve a specific problem really fast and really efficient using a real simple solution, but instead you're now restricting yourself to only solving problems using a particular framework or developing only in one particular paradigm and as a result your solution becomes complicated, slow, and inefficient. But hey, who cares about that right?! As long as it is done "philosophically and academically correct"!

If you are working with PHP and you are:

  • Always using a framework.
  • Always using only one programming paradigm (for example object oriented and never procedural).
  • Always restricting yourself to one specific set of rules of DO'S and DON'TS even across projects.
  • Following "buzz" and "trends" like using Composer is a "MUST".
  • Trying to solve every problem using a so-called "design pattern".
  • Always letting other people tell you what to do and not to do rather than to think for yourself.

Then in time you will - hopefully - discover that you are doing it all very wrong!

Recommended reading:

http://www.brandonsavage.net/you-dont-need-a-framework/

https://mwop.net//blog/2013-02-27-resigned-from-php-fig.html

https://mwop.net/blog/2012-12-20-on-shared-interfaces.html

http://afilina.com/frameworks-for-everyone/

If you have any comments or corrections feel free to email them to me.