But before we get started, I’d like to clarify that this blog post is about the Group module’s development history and decisions, not its inspiration or origins. If you’d like to read more on how I was daring enough to take on this behemoth’s development, please read the following blog post instead: (Organic) Groups in Four Voices
How did we get to a D8 version and what does that mean for the code


Initial development choices
When I joined Deeson in late 2015, the goal was to take the good parts from Group’s D7 version and release them for Drupal 8 as soon as possible. I had learned my lesson about trying to appease everyone and decided that it would be feature-poor rather than rich, but with easier extensibility to make up for it.
I knew that I wanted to completely remove any “special privilege” for my own functionality and instead focus on writing a few APIs that I would implement myself, levelling the playing field as much as possible for anyone trying to extend the module.
It was at this point that John Ennew suggested I’d use the same connection for all things added to a Group, even if it didn’t seem to make sense for some use cases. After having done my research, I found that it could definitely work on Drupal 8 but I did have to jump through a lot of hoops to get the ball rolling given D8’s young age. In hindsight, it was one of the keys to Group 8’s success and I’m happy we went through that pain then to get to where we are now.
Choices I regret making
One of the major drawbacks of having to go fast, is that it makes it difficult to go far. When I started writing Group for D8, I had not properly taken the time to completely study every subsystem of core and my test-writing skills were virtually non-existent.
This meant that I sometimes wrote code that worked well on the surface, but later turned out was not using core’s APIs properly and led to having to write some nasty updates. Example: Groups were not translatable at first and making that possible after the fact was a huge pain in the earlier versions of Drupal 8.
To make things worse, I started off with zero test coverage because who has time to write tests when all you want is to write awesome code, right? Wrong! Several of my earlier updates and even one or two of the more recent ones turned out to break something that was previously working fine. Not having tests is a huge red flag that I strictly try to avoid now. Which is why all of the more recently introduced APIs or systems in Group come with a large amount of tests to make sure they work well.