Drupal 8 is shaping up to be another Drupal 7 waterfall conversion without the benefits. Updated to Drupal 8 alpha 5.
Waterfall or rapid development?
Back in the Gordon Gecko days of the 1980s, the big rich companies used the waterfall approach to application development. Everything was big and one way, like the Victoria Falls in Africa. The waterfall approach is widely discredited and almost every other approach is better.
Rapid application development is better. There are many approaches to rapid application development, including some not so rapid approaches that are called RAD. The rapid approaches are of varying use and each approach has different benefits, making them suitable for different types of projects.
Drupal 7 was a waterfall project where everything went through massive changes you cannot reverse out, the total gain was small compared to the effort, and the time between releases was massive, way too long to be useful.
Some consider the time between the release of Drupal 6 and Drupal 7 to be acceptable but Drupal 7 was released at least a year after the point where users where ready for a change, plus Drupal 7 did not become usable for almost a year after release, making Drupal 7 two years too late.
The conversion to Drupal 8 is worse
The changes lined up for Drupal 8 are bigger than the changes for Drupal 7. There are useful changes in Drupal 8 plus some minority interests won their political battles to make changes that will slow down every aspect of Drupal 8 without really improving anything. The winners will then push to change everything to their way.
The Drupal 8 project started with the replacement of part of the Drupal code with part of the Symfony framework code to improve the Ajax and Web services. Instead of Drupal making that one quick conversion, then expanding the use of Symfony in Drupal 9, we get a massive change to large parts of Symfony and a long wait while all the useful modules are converted.
Based on the change to Drupal 7, there will be no clean upgrade path for most sites.
I upgraded over a hundred Web sites from Drupal 6 to Drupal 7 and have over a hundred to go. The big roadblock is the module upgrade path. Some modules have no upgrade path. Some modules are converted to Drupal 7 but make you throw your data away and start again.
The module upgrade roadblock is caused, in part, by Drupal 7 incorporating changes that are not document or do not have useful documentation. There are a whole lot of changes in Drupal 7 that were never tested, where never tested against documentation, and were never tested for an upgrade path. There were too many unrelated changes, Drupal 7 development was allowed to drag on too long. Drupal 8 is shaping up the same.
The changes are political
Many of the changes are political. Looking back at the change from D6 to D7, many changes were added that had no advantages, created performance problems, and were not tested in the form in which they were added. If the D7 project was professionally managed, some of the new code would be split into smaller chunks and tested one addition at a time. D7 would have arrived a year earlier with fewer changes. The other bits would be back at the drawing board or in a D8 available on about the same date as D7 actually arrived.
If Drupal switched from the watrfall approach to something more modern, the Field system would not be missing important field types, would have a working interface, and you would be able to tell the difference between the several parts of a field. Fields and internationalisation would work together without all the pain.
D8 could arrive with a real miracle, Views working either consistently or reliably with multiple tables. There are so many people working on Drupal 8, miracles are possible. The problems with Drupal alpha 5 suggest the miracle is not happening.
With a shorter smaller release cycle, the performance problems would be either predictable or curable. The band-aids slapped on Drupal sites to cure performance problems only work in some circumstances and are often a distraction from the real problems.
Imagine yourself in a remote area stuck on the side of the road with a flat tyre. Along comes a Drupal developer. You ask for help. The Drupal developer empties the gas out of the tank because that will make the car lighter and faster. You still have the flat tyre and now you have no gas.
You point out the limited distance you can travel with no gas and remind the consultant of the flat tire. The developer tells you you should have used a boat, you should have loaded the car on a boat because boats do not have tires and cannot have flat tyres. You look around at the rocky desert and think about the chances of someone finding a developer's body out here.
Most Drupal developers are better than my description but there are some who push push for their massive changes without considering what else is happening. The waterfall approach occurs because several politically active developers get all their massive changes pushed into the one big release.
Drupal 8 Alpha 5 is described in Drupal 8 alpha 5 November 19, 2013. Many of the changes are steps forward that are not complete. There are some major issues still in progress. A beta release is still a long way away. The one good thing in alpha 5 is the slow down in change. There will be an alpha 6 to fix the current problems then an alpha 7 to clean up then there might be a beta realse.
Drupal 8 has some benefits and many could be added to Drupal 7.
Extra field types
Drupal 8 includes some extra field types. Drupal 7 added some and missed the critical date field. Drupal 8 catches up. They could just add the dates into Drupal 7.
Edit in place
The Ajax style access is now a full blown Json system to support in place editing, something that will make life easier for some sites. The in place editing part could have been released a long time ago as Drupal 8 and the rest of the Drupal 8 changes could be in progress now as Drupal 9.
Read and learn
PSR is a set of conventions put together by a committee representing legacy frameworks. It makes them look similar and may lead to them working together. This is classic market consolidation with the dinosaurs trying to lock out revolutionary changes. Read more in PSR.
The main reason for using PSR in Drupal is compatibility with the Symfony autoloader. You cannot easily use Symfony without using their autoloader. Instead of adding the Symfony autoloader after the Drupal autoloader, Drupal 8 replaces the Drupal autoloading with the Symfony autoloader.
Symfony effectively doubles the number of Drupal core developers, you get all the current Drupal core developers plus all the mainstream of Symfony developers. Symfony needs Drupal more than Drupal needs Symfony, Drupal drags Symfony out of the big and slow PHP framework market, giving Symfony a real edge over Zend and everything else.
Symfony supplies two parts of Drupal 8, some framework code and the Twig text substitution system used for theme templates.
Twig is already used in some Drupal 7 projects. Twig replaces part of the Drupal template system, it replaces the template text substitution part, not the
YAML replaces the PHP .ini format for configuration files. YAML means Yet Another Markup Language but the YAML people claim it is
YAML Ain't Markup Language. The YAML developers provide the following description.
YAML is a human friendly data serialization standard for all programming languages.
So YAML is a markup language for data. YAML has evolved. It used to be incompatible with everything. Now it attempts compatibility with Json. YAML 1.2 lets you use YAML without JSON compatibility, with Json compatibility, or a muddy mix of the two. You can read more details at yaml.org.
Drupal 8 is scheduled to be a bigger change than Drupal 7 with less benefit and few changes aimed at the areas creating the biggest productivity losses for organisations using Drupal. You can add some of the Drupal 8 changes into Drupal 7 now.
Ctools is a symptom of the worst of the old fashion waterfall development methods. Will Drupal 8 fix Ctools the way Drupal almost fixed Fields?
Drupal 8 alpha 5 is out and is on D8 The.me. There are a few changes of interest.
Drupal 8 alpha 6 is out and is on D8 The.me. There are a few changes of interest.
Drupal 8 development is headed in the same direction as Drupal 7, a closed discussion on what could be achieved.
Drupal 8 introduces
State storage to replace the old variable system. Is State better or worse? Why did it take developers a year to define it then a long time to deliver something different to what was required?
Drupal specifies a lot of rules for coding with more added by convention. Drupal 8 will use parts of the Symfony framework. Symfony published their rules as PSR and are trying to make people believe PSR is a standard. PSR is also different from what is actually used in Symfony. How can Drupal adapt? What are the good bits of PSR? Will Symfony and everybody else change to PSR or will the committee publishing PSR weaken PSR to fit what they actually do?
Twig is scheduled for Drupal 8 as a theme
engine although it is not a complete replacement for the Drupal 7 theme engine.
Will Drupal 8 be faster than Drupal 7? Will Drupal 8 gain the speed we lost when converting from Drupal 6 to Drupal 7? We know some things can be faster and many site will use the new features for flexibility, not speed. D8 will offer more choices and, like D7, the choice will often be flexibility or speed.