In Defense of Frameworks

Posted by Josette Rigsby on 16 February 2012

Guest blogger Josette Rigsby has over 15 years experience in leading technology teams and delivering solutions. She has a special interest in enterprise architecture and emerging technology.

PHP has ranked as one of the most popular programming languages for over a decade. The loosely typed language has a long list of built-in functions, simple syntax and very few rules, which makes it a “go to” tool for countless developers. PHP’s ability to get things done fast continues to attract legions of new enthusiasts, which is why it is a bit surprising that the PHP development community is still divided regarding frameworks.

Everybody’s Doing It?

The buzz around frameworks like CakePHP, Zend, CodeIgniter and even SilverStripe’s recently decoupled framework (formerly known as Sapphire), might give a casual observer the impression that the majority of PHP developers have embraced frameworks to standardize and speed their development.

They haven’t.

The recent MicroPHP Manifesto, which passionately argues against the current direction of most popular PHP frameworks, has refocused attention on the topic. Although the manifesto subtly states frameworks aren’t “necessarily bad” multiple times, you could easily get the impression that PHP frameworks are large and complex code beasts that eliminate the key benefit of the language- simplicity. Armed with this knowledge, you could then shed the oppressive constraints of the framework you loved only three months ago and become one with the code – rolling your own functions and stringing together micro frameworks to build an application that reflects your true spirit.

 

 

 

 

 

 

 

 

 

 

 

Slow down there, tiger.

Why Frameworks?

Frameworks aren’t all bad, and you should not discount frameworks just because they require time to learn or slightly increase complexity. If your goal is to create SOLID instead of STUPID code, leveraging a framework is often a good choice. However, there are scenarios where you should avoid frameworks:

  • Industries or organizations where regulations or policies discourage or prohibit use
  • Small or simple sites with mostly static content
  • Applications with exceptionally demanding performance requirements
  • Projects that involve making only a few enhancements to a large and established code base

For everything else, you should at least consider using a framework.

Using a framework is not without costs. You must take the time and effort to select, learn and eventually upgrade the framework. (TIP: If you are on a team with more than 2-3 people, consider having a lunch and learn to accelerate the process.) Although frameworks typically handle the most common scenarios, they may not address your specific use case. If this occurs, you will need to invest time in figuring out how to solve the problem. Many frameworks include extension mechanisms to make adding functionality easier. Finally, leveraging a framework means giving up some control. You must trust that the creators of the framework leveraged good design practices. You must trust that they tested. You must trust that they will not make breaking changes.

No tool is a silver bullet, but if you select a popular framework, you are likely getting a better product than you would have created internally. Many frameworks, like SilverStripe’s, are based on years of experience implementing content management functionality across multiple industries and organizations; unless you are lucky, your project team doesn’t include the same depth of experience. Further, many open source PHP frameworks have hundreds of contributors and thousands of users that provide a rich source of collective knowledge and peer review. This usually results in a solution with fewer defects and a better design.

A better code base isn’t the only benefit of leveraging a framework. Frameworks can:

1. Standardize Architecture – Most frameworks incorporate design (e.g. decorator) or architectural (e.g. MVC) patterns. Using the framework incorporates the pattern into your project. Additionally, frameworks can impose other structural constraints like file system organization, which make it easier for multi-member teams to deliver a solution. Micro frameworks can provide value in this area, but if you need to use more than one, you may have to deal with conflicts and inconsistencies in how they are organized. Obviously, using a framework isn’t the only way to achieve architectural consistency, but a framework can make it simpler.

2. Minimize Infrastructure and Utility Development – Frameworks often implement infrastructure concerns like caching, data connections, logging and security. These commodity features are required, but don’t significantly contribute to business value. If you don’t feel an urge to twist wires for your own USB cables, you shouldn’t feel a need to write lines of code to produce a log file. Don’t reinvent the wheel; spend your time designing and delivering core solution features.

3. Provide Broad Support Options – If you write your own framework, you and your team are the only source of knowledge about its use. If you use a framework you get forums, documentation, other users and potentially third party solution providers to help you solve problems.

4. Reduce Staff Onboarding Time – If you select an existing, widely used framework, it is possible to add staff that already know the framework. This reduces the time and cost associated with onboarding new resources. You should not underestimate the value of this benefit. Labor is significantly more mobile than in the past. It’s not uncommon for all members of an original implementation team to leave an organization before an application is retired. When there are no humans available to guide a new developer, the use of a framework can provide tremendous value.

5. Reduce Technology Debt – One of the benefits of frameworks you might have overlooked is reduction in technology debt. Teams often eliminate items that don’t contribute directly to business value (e.g. configurable logging) to complete a project on time. Unfortunately, these small concessions can have large and long lasting negative impacts. Using a framework allows you to get many of these often omitted features without investing the time to design, develop and test them.

I am not suggesting developing custom code or using a micro framework is bad. Every problem is different and these techniques are the right solution to some problems. However, sometimes implementing the fastest easiest solution on a micro level can result in complete chaos at a macro level. Do you use a PHP framework? Do you feel that it has benefited your solution delivery? We would love to hear your thoughts.

 

Post your comment

Note: Comments are moderated and won't show until they are approved

Comments

  • Consider this as a different scale frameworks and you get a perfect picture of a PHP roadmap from its birth. Once upon a time there were no frameworks, and, just imagine, people mixed PHP and HTML (although some still do now) - childhood. Then there was a perturbation period, a number of different approaches, template languages over PHP, ugly formed CMSs (some are still alive), and mother nature for developer sake selected a few to survive. Now, what some may call a maturity is still that period and it will last forever, and many species will be abandoned to live in remote forests, some dominate. However, each survived has its own niche, and what's more important, dominating species will die as soon their feeding chain will be cut.

    My point is it might be useless to compare frameworks of a different scale, moreover inappropriate at all. Or, better, imagine PHP developer who started with some MVC framework on his first days (let's say Z), and was there for years mastering all the whistles and bells, achieving the top in that, and one day he faced something that is beyond that, where database connection (bad example) has to be coded himself!

    After this, is one can be called a PHP developer or Z-framework developer? I'm pointing is out by comparing available docs for PHP with that imaginary Z-framework, where the latter has an overwhelming amounts of "handy", "useful" etc libraries, models and it makes one to learn some other language than PHP. This is my argument to the article, although does not reflect my position.

    Posted by Alexey, 2 years ago

  • @schellmax; I checked to see if we had any documentation on the Framework as a standalone. The answer, unfortunately, is No. The release of the Framework is part of SS 3.0 and therefor we do have the feature in place but no documentation yet. We have that on our to do list, since we know how important documentation is, but it is not a trivial piece of work and therefor we have decided to get the feature in first and the documentation will follow.

    Posted by Kerstin, 2 years ago @silverstripe

  • Russ I completely agree except I think they people "THINK" they are bloody good coders. :)

    Posted by Josette Rigsby, 2 years ago @techielicous

  • I fail to understand how anyone having used a framework in any language, would not be swayed by the advantages they hold.

    This leads me to believe that those folks who _are_ dissuaded by them have not tried any or are just bloody good coders, able to knock-up architecturally sound apps in as much time. I would argue however that the latter are few and far between, even more so in the PHP world, having long-ago switched to other languages with more rules and arguably better OO implementations.

    Posted by Russ, 2 years ago @therussdotcom

  • are there any hints/tutorials how to get started using sapphire as a standalone framework without the cms module?

    Posted by schellmax, 2 years ago @schellmax

RSS feed for comments on this page | RSS feed for all comments

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.