
Picture credits: Sue Reno.
It look us another 8 months to get this post. During this time, we deliberately and slowly realigned ourselves toward the adoption of new frameworks - feature-by-feature, with performance and stability benchmarks, and one step at a time. In addition, every customer is slowly transitioned to the new platform based on feature-readiness and enterprise-grade stability. We're out-of-the-woods, but still fragile in execution, a few more months of calm waters with smooth sailing should take us across the finish line. So, what did we do?
I started writing code. Given the older version of the platform, using translators to get a newer version up-and-running was surprisingly easy. Given my experience interacting with customers, I knew exactly what we needed and spending a couple of hours a day building them like lego got a lots of things done. The key is consistency, contributing whatever you can everyday makes a lot of difference. It gives visibility into what's happening in code, what are the gaps, and what requires immediate attention. A lot of this is driven by customer requirements, but knowing how long it takes for a fix is key. The earlier challenge was the inability to wrap my head around timelines, things as simple as adding a shader sounded soo complex, but there are nuances and basic shaders are quite simple to implement and easy to integrate. The other benefit to this is the depth of understanding of what's possible with materials - somehow adding materials, shadows, or lights to the 3D scene felt impossible in the previous version, but turns out these are easy to do, and performance efficient if the structure of code is controlled well.
Nothing against developers contributing ginormously to advance the state of software in the world today, this is primarily a business requirement since enterprise customers do not prefer open-source software (OSS) due to the risk of non-maintenance or the uncertainty of OSS authors converting the license to a paid model. This constraint forced us to build whatever we need, to whatever extent possible, in-house. Given the speed of creation of small modules, the ability to author and utilise them is quite fast. We still use OSS, but it's limited.
Every snippet of code enters the development pipeline along with an accompanying functional testing script. These scripts are from the same translator that puts the code block together. Since there's some prior context, it is quicker to generate a test script. While these test scripts are not exhaustive, it's a start to the development pipeline that can be augmented. You would be amazed to find how many things just stick once added without any changes. I'm sure there are 1000s of packages on NPM and Github that people use today and there hasn't been a single line of code changed. The bottom line is once the module and script goes into the deployment pipeline, it tends to stick there unless it causes major issues in the software. Get functional testing committed along with the feature as a habit.
Instead of encouraging developers to upload a code block into a translator and asking it to explain (which I do for many code blocks as a starting point), I think it is better to get a summary of the conversation from the translator as a document. This captures the approach and thought process behind the structure of the code, and this is valuable because we tend to forget when reviewing after a few months and the document acts as a good refresher to continue from where we left off. This also prevents code from going into the training pipeline of GPTs in general (not that the code is proprietary, it's become a commodity now, but I think there's still the mindset to avoid uploading entire code blocks to translators).
Well this is the hard part isn't it. Getting people to follow the above approach is a challenge, we get polite head nods and little action. I think this took the longest, and even now it's a struggle. We get carried away by the priorities of the day and after a few weeks of non-process, we are back to the fragile old self again. I think the only way to do this right is to work with people with the right attitude. We went through a lot of people during this time matching them with the desire of doing the tasks well, and more than 90% of them were verbatim reiterating translators while consuming more than their share of resources since their work is useless and the entire thing was redone every time. These folks just cannot be the ones building quality solutions to many of today's hard problems. This is not only true of people we try to hire, but also of partners we want to work with. I gave ourselves a score of 4/10 here, and I revise that to 7/10 today. A much needed improvement from six months ago, but still a long way to go.
The only way to create a long lasting company is to create long-term value for customers. And creating value to customers take time and effort. The platform's features are a small part of it, but where does the solution fit-in is a larger part. To ensure the solution fits in, we need to build the plumbing, secure access to ensure the right folks have access to it at the right time, and the solution behaves like a lego instead of a jigsaw puzzle (the former is more flexible than latter) inside the customer's technology ecosystem. We have been fortunate enough to understand these things first hand, and bake these processes into the solution instead of building them every time for a new customer. The next few months are crucial to sustaining and optimising our well-oiled machine.
While we are out-of-the-woods, next few months are crucial to complete our transition and set a deadline to sunset our Angular platform. To do this successfully, we need to keep an eye on performance and user experience. And I'm glad to not talk about processes, people, debt, etc. I need to ensure an effective weekly implementation with process and without substantial delays for the next few months.