As a platform development team, we don’t just add shiny new features to our applications. We also spend time improving on the features and functionality that we already have. The most visible example of this in recent years has been our move from the older Origins design system to Lens. This has had a big effect on the look and feel of a wide range of pages – from longer, content-rich pages such as Courses and Events to “hub” pages which offer links to more specific content such as Topic and Landing pages.
These kinds of improvements also happen on the parts of the applications that you cannot see. Every seventh week is our “stretch week”, where the team are able to focus on improvements to infrastructure and to work through smaller stories which otherwise would not be picked up during our normal sprint cycle. From my perspective as a back-end developer, these normally take the form of security updates and bug fixes which weren’t critical enough to be dealt with during the sprint. This sounds very unglamourous, but I do enjoy tracking down and squashing code bugs.
We also have some longer-term tasks in our stretch weeks which tend to be more far-reaching than the average task. It is one of those tasks that I will show you today. We struggled for a long time to name this process and we couldn’t come up with anything particularly succinct. In the end, we just decided to make a verb from the name of the developer who started this whole process. So, today, let’s talk about Mironing!
But what is a Miron?
Miron joined the team in the heady days of May 2019, and brought with him a youthful energy and a mindset of asking “Can this be better?”. He spent a lot of time looking at our processes and seeing where improvements could be made. Then came the big one. He took a look at our publishing system and devised a new and improved version, taking the lessons we had learned from componentising our Lens content types. He put in all the groundwork of building the structure to support Mironing, and provided documentation and examples (which have proved incredibly useful – always comment your code, kids!).
As an aside, Miron’s legacy isn’t just Mironing. He is also now the face of our story estimation process. If everyone agrees on an estimate, we get a “Zgoda!”. This is probably one of the more unconventional ways that a member of the team can still have an effect after they have left for pastures new!
But what is a Mironing?
The existing publishing process has a file for each content type, plus one large file containing the necessary processing code for every component in Typecase. This seemed like a good idea initially, but the number of components has only ever gone up, so this file quickly became unwieldy. One of the main aims of Mironing was to give each component its own file and to bring down the oppressive publishing monolith.
As each component tends to have fields in common with the others (almost all components have a title and summary field, for example), these could be abstracted out into an includable file to reduce on code duplication. Therefore, what should remain in each component’s file are the fields that make that component unique, plus any fancy processing we wish to do on the information that the publisher receives from Typecase (for example, formatting a value as currency, or constructing a class name to use for styling).
As if that wasn’t enough, where sensible to do so, each item belonging to a component also has its own file of configuration. For example, an Events section will contain up to three event items. As with the component config above, each type of item can have its own set of fields and processing.
But is it an improvement?
For the average visitor to any page generated by the publisher app, they won’t even know that this change has happened. However, for a member of the Platform Development team – current or future – Mironing will mean that the codebase is a lot easier to read. While the functionality is more complicated, that complexity allows for some very cool (and sensible!) things to happen. The upshot will be that the code is easier to maintain, easier to extend and easier to read.
But when will it end?
You ask so many questions, just let me finish! The process of Mironing isn’t complete yet. The two methods of publishing can exist side-by-side until the point that all content types, components and items have been successfully Mironed. The nature of this kind of invisible change is that they often aren't as high a priority as more obviously "customer-facing" changes, but with our outside-of-sprint stretch weeks, we have an opportunity to make gradual progress towards the end goal.
Of course, once we get there, some young go-getter will ask "Can this be better?".
Respond
