Starting projects with Drupal 8 - Our strategy in 4 steps

We are finally almost there to release Drupal 8 RC1. For us, the release candidate means that Drupal has a stable API, a feature freeze and "should" be free of critical bugs as far as there are no new ones found. That counts for Drupal8 core. We will start with Drupal 8 projects from the release of RC1. The question is only: How to create estimations for a system we, honestly spoken, don't know yet with the same depth of details as we know Drupal 7. There are so many pitfalls related to the decision making of Drupal 8 architectures. As we usually need many contrib modules in our Drupal applications, and this will not change in Drupal 8, they are not yet ready and stable enough for a bug free experience in our development team. So we are all in a difficult situation where we want to start with Drupal 8 from now on the one side but want to be able to estimate projects reliably on the other site. There needs to be some trade-offs which I want to discuss in this blog post - so please feel free to add your thoughts in the comments below.


1) Focus on Drupal core and REST

Drupal 8 core provides already so many features we need for data queries, data structure and user management. Nevertheless there are many useful contrib modules out there that are needed to render the query results in the way we need it (formatter). Some are already ported, others have not even started to be ported to Drupal 8. Struggling with bugs in contribs can take a huge amount of time in projects. That's normal as we all miss the experience with new "things". To prevent our team from estimation failures, we will start with the headless approach in Drupal 8. We've already made our experience in the last year using Drupal 7 headless and it works well. This means that for applications or content sites where no requirements are against this approach, build our own frontend in HTML/CSS/Javascript to be independent from most contribs.


2) Try to split projects

The bigger the project we want to build with Drupal (not only Drupal 8) the bigger the risk. As in Germany most clients want fixed prices for their projects, we need a fine-grained planning of small feature junks. Keeping project requirements as small as needed reduces the risk to oversee some details that will crash your estimation during the development. From an agile perspective small development steps with detailed requirements reduce also the risk to build a product that nobody needs.


3) Give some discount to contribute

We will offer our clients an up to 10% cheaper price if they pay us by the hour and allow us to fix bugs in core and contribs. This helps us to contribute and improve the code base of Drupal 8 and contrib modules. Our clients as well as the community will benefit from a fast growing and stable code base in the future as they put their strategy on Drupal 8.


4) Update early and often

Whereas the update frequency in Drupal 7 becomes slower, Drupal 8 is almost there and as more and more people will use Drupal 8 and contrib modules, the more bugs will be reported and hopefully fixed. This means for us that we need to update early and often to see code and feature changes early and react on them. Keeping modules out-dated for a long time, even for none security related updates will bring additional risk for a broken site. The bigger the difference between your current code base and the latest release, the bigger the risk that your site will break with your update. The same rule as working with GIT in a team Update / GIT pull early and often and fix issues immediately. That's why we integrate Drop Guard also in the process of our on-going development and not only in the deployment process of critical security updates. With the right setup, we don't need to care manually about our update workflow. Drop Guard will do. You can start with Drop Guard for free during our beta period and automate updates as well.