To framework or not to framework?

Posted on 2015-11-10.
What level of complexity do 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:

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. The more abstraction you use, the less efficient and 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 and principles when programming!

The more abstraction you use, the more difficult it becomes to maintain and change code. And don't think for a minut that a code block consisting of multiple processes always and by nature benefits from separation and a single responsibility principle. If that code block is easy to understand and it is running efficiently, you can be sure that splitting the code block up into multiple independent methods in multiple independent classes will most likely not only decrease efficiency, but also decrease readability.

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. Don't polute your code base with principle programming, concern yourself with efficient problem solving instead.

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 products (even when free).

Another fact, expressed in a very clear language, is that:

All general purpose PHP frameworks suck!

-- Rasmus Lerdorf

General purpose PHP frameworks 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.

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

If you really want to understand what Rasmus Lerdorf is talking about you can compare this to the same fact that all general purpose CSS frameworks also sucks!

If you just need to style a couple of tables and a single user form why would you load a multi purpose CSS framework bloated with styling blocks for tons of stuff you would never need? It only makes your website slower.

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.

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 tons 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 on the contrary supports imperative, functional, object-oriented, procedural, and reflective paradigms and is as such a huge toolbox with lots of different tools that makes it possible to solve many problems in many different ways - not just one way.

This doesn't mean that general purpose frameworks are useless. They do have some use cases, but you better make sure you understand the problems that always follows.

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"!