About 4 years ago we got an idea that we could use a new framework written in TypeScript. One of the main reasons was that we wanted to switch to Angular 2, which is written in TypeScript and we didn’t want to combine TypeScript and an old framework written in JavaScript. Moreover, we were aware that the old solution had some issues and because we like to learn from our mistakes we have decided to make a new and better framework in TypeScript. The project had moved forward and after some time we did have a shiny new framework.
Time for an experiment
So we have a new framework, now we just need a project to test everything and make our first application. So what could we do? Ideally, we’d like a project that we can not only test everything on but also be useful to our customers and become part of our ecosystem. We discussed what might that be for a while and finally decided that Ad Management (a part of the system for creating and managing ads that are eventually shown to a visitor to a website) is a good candidate for the first application. Why? We figured that this particular piece of the system is separable from our existing monolith and can work independently. Moreover, it was at the time when we occasionally found out some shortcomings in the existing Ad Management and it seemed that we would have to make some changes and program new features there anyway. Things like, support for new ad types or complex ad formats, which are ads that consist of multiple images. So it started to become clear. Hooray for the new Ad Management.
We’re going to analyze
Making a great new Ad Management shouldn’t be a problem for us. After all, the company has been in the “ad tech” business for more than 20 years and some of our colleagues have developed something similar in the past. Quite a few people were involved in the last version of Ad Management, which we knew had some bugs. Plus, we still have customer support on hand, where colleagues get closest to the real world when using our systems. Simply put, we have the experience and now also a vision on how to use this experience into building an awesome new product, so we sit down in meeting rooms to make it happen.
We start with a comprehensive analysis of the domain, we talk about what an ad actually is, what it is used for, what it consists of, what types of ads currently exist and what types of ads may appear in the future. We also talk about what we want the new ad management to be like, what it should be able to do or what previous mistakes we don’t want to repeat. We also need to design the backend, API and of course the UI. That’s where we felt we should take a big step forward, because the old UI looked something like this and our new vision was a bit different.
In addition to the redesign, we wanted to start supporting all ad formats according to IAB standards, offer various flexible ad templates and, last but not least, complex formats that seemed most complicated. This is because the final ad needs to be assembled from multiple images and then rendered together on the page. But generally speaking, we wanted the new Ad Management to be as generic as possible so that we would be prepared for how the advertising market will evolve. In short, ready for everything, even for what doesn’t exist yet.
After a few weeks of analyzing, we had the first prototypes of the new UI. For classic ads, we planned for the user to choose what banner they are currently preparing and then see how the banner’s appearance and behavior change as they change the settings in real-time. With the use of templates, we wanted to allow customers to create any ad format they like. All in all, nicely laid plans and the UI prototype looked something like this:
We start programming
We dive into the development and a new app is really starting to take form. Along with that we are discovering and fixing the shortcomings of the new framework, making more and more improvements and last but not least learning a lot of new things. On the one hand, this is great, but on the other hand, it slows down the development of the app itself a bit. Weeks went by, Ad Management slowly grew, but we still didn’t have anything that could be sent to production and start using in the real world. In the meantime, however, the pressure to solve other customer requirements started to grow and we started to feel for the first time that it would be a good idea to finish the app.
The ironic thing about that situation was that we didn’t feel the pressure to complete Ad Management itself and if it wasn’t for other requirements that were slowly but surely growing in priority, we might still be working on the Ad Management even today. So we started asking ourselves – “Where is actually the customer who is waiting for new Ad management?”
We are looking for a customer
So we are at a stage in the project where part of the application is already in the process of completion. It is mainly the part for managing standard banner ads and we are starting to look for a customer who could test it and give us some initial feedback. ‘But it seems that no customers are talking about any new features needed for banner ads, let alone the complex formats.
We’re starting to realize that we may have made a mistake somewhere, and we’re trying to double-check if new ad management features and the need to support new formats are still part of some strategy and will really be needed in the foreseeable future. We learn that more urgent requests are already on the table and among them, for example, support for video ad serving in one of our legacy systems. At first we were a bit relieved, because video ads also need to be managed in some kind of Ad Management. The application we’ve been working on for weeks is generic enough to support video, and we already had some prototypes of the UI as well. But the situation changed and we already had a customer waiting on the other side with a clear date when he wanted to start using our legacy system for video advertising. After several discussions, we found out that there were some troubles in integrating the new Ad Management into the old system and various other unknown issues that could potentially bring complications. Thus, we decided it would be safer and faster to program video support directly into the old system. So the development of the new Ad Management was put on ice. At least we could use the prototypes of the UI that were created during the analysis. So ideas for automatic conversions to different video formats or quality optimization for different types of devices didn’t go to waste. A positive outcome in a sense.
What we have learned
1. If we want to make experiments with something (in this case a new framework), we should also set a goal and an end to the experiment. Ideally, something smaller, where we try out everything we need. Definitely not a big project for a few months.
2. If we want to come up with a new and beautiful solution to various customer problems, we’d better verify (maybe several times) that they actually have such a problem. If there is no customer waiting on the other side, there is no pressure to complete the project and no way how to continuously validate that the project is moving in the right direction.
3. Don’t try to develop the application to perfection right from the start and then include the customer. It is worth developing small meaningful parts of the app and then collecting feedback on them. We might have found out in time that we were doing something that nobody needs at the moment. We touched on a similar topic in this article.
4. If we know that a new part of our system will need to be integrated somehow with an older part of the application, let’s think of a way to do this at the beginning of a new project rather than at the end. This time we discovered the difficulties of that too late and it was one of the reasons why the integration never happened.