Knowledge sharing between developers in a fun and effective manner can be a challenge. In 2018 we started to improve this within VI. Introducing: The Guild system.
One of VI Company’s goals for 2018 is to improve the way us back-end developers shared knowledge about our projects and day-to-day work. It often came down to periodically sitting in a room with all back-enders talking about various subjects. For instance, when we wanted to improve VI coding guidelines, we would have long discussions with entire disciplines. For some subjects this is fine, but not every discussion requires or interests every developer. Some of these meetings took ages, others were so dull that many of us lost focus halfway through the session. On top of that, give 1 problem to 10 developers and you get 10 working solutions.
To solve these issues, we came to the creation of the Guild system*. Each guild has the leading role regarding the innovations on a certain subject and has the power to make changes within VI Company. The guilds act in an advisory way and try to support the other developers with knowledge or tools. This ensures VI’s developers don’t reinvent the wheel time after time.
While the current guilds mostly exist of backend developers, everyone who works at VI is welcome to join one or more guilds and participate in the discussions. Some of our guild members include frontend developers, system admins and sometimes non-technical colleagues. While everyone is welcome to join, we aim to keep the guilds at a small size. This keeps the meetings short and effective because you deal with less people. Of course, information and the progress from the guilds is being shared in company-wide meetings so that everyone is informed about what is being worked on.
So you might be wondering what kind of guilds we defined. When we started this initiative, we (again) sat together with all developers to define the subjects the guilds should be formed around. We ended up with 11 ideas, but since we do not have enough people and/or time to start with all those ideas at the same moment, we prioritized them and selected the ones that required the most attention.
CI/CD (Continuous Integration / Continuous Development)
This guild governs all the decisions and tools regarding the CI/CD process. For example, maintaining custom build- and release tasks in Azure DevOps (formerly VSTS). These custom tasks are being used by a lot of projects within VI. The guild members maintaining these existing tasks and develop new tasks when new needs arise. They also help the other developers with their project’s build/release pipeline optimization and keep an eye out to make sure the pipelines are setup in a correct and maintainable manner.
The security guild is looking at both software- and hosting security within VI Company. Some examples regarding the software part: static code analysis scanners are being investigated so we can periodically scan our applications on common security errors. Next to those scans, we also research how we can improve the use the standard security headers supported by browsers to protect our applications even better (for example CSP1).
Hosting security is the responsibility of our system administrators rather than the developers but is still an important part of the guild. With our (latest) applications moving to Docker, both Windows and Linux containers, comes a new landscape of networking security that needs to be explored.
QA (Quality Assurance)
QA is overlooking the coding standards and testability of our solutions. They are currently working on defining and monitoring a level of quality for our software. Besides reviewing the current guidelines, the guys (sorry, we still need female developers at VI) made plans for end-to-end and load testing to ensure good performance of our applications.
For the past year I have been part of the security guild and have mainly been working on the security headers part. Together with some colleagues, we created a way to review CSP reports4. You might have heard of Report-URI5. This website basically does that for you, but since we mainly work for financial institutions, who don’t like to share any data with third parties when they don’t need to, using that service was not an option. So instead, we build an API in .NET Core with an endpoint where browsers can send their CSP reports to and a Node JS dashboard where developers can review those reports.
I think the Guild system works very well, especially if you compare it to the way we used to work on these subjects. You get more separation of duties within the developers and not everyone has to worry about each and every subject. Also, you get better and faster results with smaller groups of people.
The future of guilds at VI Company
As mentioned, right now we have three active guilds. Currently those guilds still have more than enough tasks and goals to worry about but in the future, we certainly want to expand to more subjects like, for instance, Logging, Architecture and Database/Storage, but also to a less-technical subjects like Recruitment and Branding.
Any questions about this article? Feel free to contact us!