Technically speaking: Retro 2021

What did the year 2021 look like at Druid, from a technical point of view? What is to be expected this year? It’s time for a brief recap! I’ll go through where we are in terms of tech and tools, and share some of our plans and ideas for the future. Naturally, we always choose technologies according to each customer’s needs – technology is a good servant but a bad master. But it’s also important to keep our tech stack consistent and manageable. Proven and reliable open source solutions is the path of our choice.

Frontend: more and more modern JavaScript

Since we do web development, we use JavaScript – modern or vanilla – in all of our projects. The use of modern JavaScript frameworks has been increasing significantly during the past few years. Currently, we have +10 customer projects with modern frameworks. React and Vue.js are the most common ones, and we also use Next.js (React based) in one project and a Stencil based Design System for a customer who already uses it in 3+ projects. The solutions vary from full Headless solutions to embedded “widget” kind of components.

In addition, we use a modern JavaScript stack for theme and JS building (e.g. Webpack) in most of our Drupal and Symfony projects. In some of our new projects we are experimenting on Tailwind CSS, a utility-first CSS framework.

Backend: mostly Drupal…and something else?

Drupal still maintains its solid position as our go-to CMS solution. Last year we were busy with upgrades from Drupal 8 to Drupal 9, as version 8 reached its end-of-life in November 2021. Almost all of our Drupal 8 projects have now been upgraded.

This year, it’s time to say goodbye to Drupal 7. The end-of-life has been a long time coming, and it’s finally happening in November 2022*. We’ll be having at least four major upgrade projects to re-create Drupal 7 sites with Drupal 9 this year. Upgrading from Drupal 7 is a much more laborious effort than from Drupal 8, because the technological changes between versions 7 and 8 were substantial.

*Edit 24 Feb 2022: Drupal 7’s end-of-life has again been extended by one year to November 2023.

When Drupal 7 is gone, there won’t be major upgrades anymore. Drupal’s product development has shifted to a more modern continuous development process where new features and improvements will be released in a faster cycle, with less upgrade effort. Drupal 10 will be just another version of the same codebase as Drupal 8 and 9. I’d say we could just drop the number and call it “Drupal”.

In addition to Drupal, we have done multiple Symfony projects. They are mostly apps or tools where there is no need for a CMS: time reservations, digital signing, data enrichment, questionnaires, launching sites and APIs. Did you know that also Drupal is just another “app” created with Symfony? On the JS side we are interested in test driving NestJS which seems quite similar to Symfony in terminology and logic. Synergy!

Anything else on the horizon for us? Well, we are planning to test some JavaScript headless CMS solutions to see how they compare with Drupal feature-wise. Serverless is on the table when delivering these apps. I think Serverless is like using a taxi to get from point A to point B instead of owning the car and filling the tank by yourself.

Hosting

Our hosting comes in many forms of Kubernetes. It’s good to not put all the eggs in the same basket so we have sites and apps running in a few Managed Hosting services. But we also have sites on customer’s own environments, e.g. Azure, Google Cloud Platform and OpenShift, and still some sites and apps that are running on customer’s virtual servers.

Tooling and DX

To control all this, one needs tools. And boy, do we have them.

Last year PHP got versions 8 and 8.1 which both improved the language and the performance yet again. Also Composer (the package manager for PHP) got V2 which is way faster. These two combined are actually saving the environment on their part as the energy impact will be smaller!

We have many in-house tools here at Druid. We have aimed for consistent tooling across our projects regardless of whether we use Drupal, Symfony, WordPress, Node8-16, Docker, host, and so on. We run our local development on Docker containers with Stonehenge. We use Make based tools to command our local projects in a common way.

For GDPR-compliant data handling in projects, we created a GDPR dumper solution (which is worth another blog post). For custom environments which our customers might have, like Azure or plain virtual servers, we have our own Druid flavoured Docker images where we run Drupal or PHP apps. As to CI/CD, we are quite omnivorous: mostly Github Actions with Gitlab CI, Azure Pipelines and Jenkins as toppings.

/r/random

New Remote Development tools are something I’m interested in testing this year. It seems there are solutions coming from left and right: Github Codespaces, Jetbrains and Gitpod, to mention a few. With these solutions, the projects are running in the cloud and your IDE is just a window to that. No more running projects on your old war horse laptop!

We are also doing some interesting product development that has something to do with launching sites in high volume. More about that later on – stay tuned!

New experiments

We always keep our eyes open at Druid and like to test new, interesting tools and technologies. Twitter is my source of shiny new tech to experiment on. Below are some new ones, and some that have been trending for a few years already, that we are testing or would like to test. What do you think of these? Any other must try tech that you can recommend? Let me know – you can find me on Twitter!

Do you also have an interest in some of these technologies? And some experience too?

We are looking for new Druids to build a better web with us. Maybe you could be one of them?

Get to know us

The road to self-organization

Self-organization is not a new concept in the software business. Self-organizing development teams have been a part of the discourse within agile software development for about twenty years now. Could the same sort of self-management be implemented at an organizational level? What sort of secrets and stuffy policies prevent having transparency and complete control of your own work at every level of an organization?

Everyone who’s ever tried delegating knows that it is hard to relinquish power, and that your own vision of the perfect end result for the task may differ from the vision or execution of the implementer. But even the worst micromanager will at some point realize that you can’t control everything. Particularly within specialist fields the greatest understanding of the best working practices, or whether the work at hand is even relevant, is with the expert working on the task and not with the management.

If we start off with the basic idea that you end up having in your payroll people that are in full possession of their faculties and who want to succeed at their work, where should you draw the line concerning authority? Can people decide for themselves what tools they use, what policies they follow on projects, when they take their holidays or what benefits they can enjoy?

Transparency is a prerequisite for working together

In the presentation I held at DrupalCamp Finland + Baltics (starts at 42:11) I went through how we have developed our organizational hierarchy and decision making processes here at Druid. We are a company founded by five owners, most of whom still work on every day “menial work”, which brings its own aspect to the company. For us it has enabled the development of a strong culture of self-organization.

My own experience has taught me that the biggest obstacle for self-organization is the lack of transparency. The company’s financial situation and projections are either only known by few or are too obscure to be of any use in the decision making process. Some of the information may be confidential for a good reason, but access to some of the data seems to be limited purely due to tradition.

Here at Druid the aspiration towards transparency has been built-in for the whole of our existence. We have conducted varying experiments and have gradually learned what works and what doesn’t. The biggest epiphany has been that raw data does not a happy druid make; if decisions are to be based on information, you will need interpreters for that information on every level of the organization. When systems can’t produce comprehensible data, you can shift some of the responsibility of clarifying that information to these interpreters.

Teal and self-organization at Druid

In practice, self-management is a very labor intensive management paradigm to implement. It requires actual shared responsibility, transparency and leaving your ego at the door. In addition, adhering to laws and directives can create headaches. Along the years we’ve experimented with different models of management and have met varying degrees of success in self-organizing. Now, in the latest effort to develop our organization, we’ve explored the Teal philosophy and are steering ourselves in that direction.

Teal is an organizational model introduced by Frederic Laloux in his book Reinventing Organizations. The model dismantles traditional power hierarchies and structures, allows for self-organizing with full responsibility for your own decisions and lets you be yourself, an autonomous human being, at the workplace.

Swarms, advice and conflict resolution

Our Teal organization is not completely without hierarchy. But instead of power hierarchies we have contextual hierarchies. Structures are created and removed according to need. For example, those of us that are interested in hardware acquisition can form an ICT swarm and start asking for bids on new phones or computers. If the swarm’s enthusiasm abates or if its goal is reached, the swarm ceases to be. The swarm commits to a certain goal and is responsible to the rest of the organization that it will provide value.

However, it is not practical to form a swarm for every decision. That is why we make use of an advice process. Each druid can, when identifying an issue, make a decision to fix it. The decision maker is expected to first seek advice from those affected by the issue and also the experts on the area the decision pertains to. The purpose, however, is not to reach a consensus: the power, but also the responsibility for the decision, is with the decision maker.

Getting others involved, and the fact that everyone is acting as themselves at the workplace, inevitably also leads to conflict. In the absence of a supreme arbiter, conflicts within the organization have to be settled in other ways, and we have a process in place for just this. It should be noted that conflicts should not be viewed as insurmountable obstacles but as learning opportunities.

We are in no way claiming to be a Teal organization through and through. There is still a lot of work to be done; old structures need to be relinquished while still keeping everything under control, transparency needs to be constantly increased, and people need to be inspired to take on the challenge.

We, however, are firmly on the road to becoming a teal organization, and are genuinely willing to give it a chance in the lean spirit.

PS. If this sparked your interest, you might want to take a look at our career site to see what we have to offer.