As developers, we tend to focus a lot on solving problems. It’s what we do for a living after all, we receive someone’s problem and we code up a solution. After a while, we develop a keen eye for problems that need to be solved. That’s just what we do, but in doing so we often overlook all the obstacles we did overcome, and just how much our productivity and quality of work have improved over time. On occasions you will have one of those meetings where you start dissecting a big problem, and you feel like solving it will take forever, like you shouldn’t even bother. You start asking whether we’ve even solved anything that big. On such occasions, it’s very important to look back at your achievements.
The last year for iSolutions
Don’t get me wrong, a year ago iSolutions was already a great place to work at, but like every other company on this planet we had a few systemic problems to fix, and a few new hurdles were ahead unbeknownst to us. At the time, it felt like solving these issues would take years. Today, we have already tackled and solved many of these issues. I want to highlight a few of these changes of various nature, as a tale of how advancing slowly and steadily leads to big improvements.
iSBets in the cloud
For the last 14 years we released iSBets on server farms managed by our customers. Virtually all of them were actual server farms, where the customer had full control of the machines and the ability, if needed, to scale vertically to the most powerful machines available. This was handy, as it meant we never had to manage the infrastructure directly (even though we did have a pretty sizeable IT team to work with our customers). With the advent of cloud services, we realized we had a chance to offer more to our customers: a fully managed solution, where the customer didn’t need to deal with the farm at all. One year ago we had the idea in mind, but were nowhere near that goal. Today, we have a fully running customer in production on AWS and another one coming soon. We can whip up a new environment within a few weeks (and we are still working to improve that), compared to the months or years that it took when we had to rely on third parties. We were also able to greatly improve the startup process of a new customer, going from almost a year to about three months between nothing being present and the customer being fully online.
Cleaner code
When you have a 14 year old product, you often have a lot of bloat. Unused projects, complex features used in the most basic way, leftovers from past endeavors, you’ll see it all. We often talk about cleaning up the mess, but it’s very hard to actually measure how much garbage we pick up, and thanks to the aforementioned tendency to see the problems and not the achievements we often have a pessimistic outlook. So imagine our surprise when we realized that exactly 1 year ago iSBets was made up of double the number of projects it is today. It used to be 200, today it’s 100. All of those projects represent code that we either deleted or cleaned up, which means it’s much, much easier to develop on it because you don’t have to pay attention to a whole bunch of references that you would break but weren’t actually used for anything.
A more modern product
A year ago we were paying the price of having a very old software, with choices made when many modern technologies to solve complex problems simply weren’t available. I want to highlight a couple of these that we’ve recently updated.
- A betting software’s live page is the core of the operation. It lets people bet on events as they are happening, creating lots of engagement, but requiring incredible performance to keep up with the most updated odds. We used to have a polling mechanism to update these odds, causing a non-trivial amount of traffic and creating a pretty heavy burden for our system, which needed to continuously answer to clients’ queries with the latest odds. This meant we need to have either very powerful machines or a very hard to use live page. We’ve since changed that: the odds on the website today are updated in real time, as our system receives them, through the use of WebSockets (implemented with SignalR). Our grabber directly sends the updates to our web server through Redis, which in turn sends them to the client. All of this happens with very little load on the system (we don’t need to read the odds from the database) and with blazing fast response times (gettin the odds from out backend to the client’s web browser takes in the order of 100 ms).
- If you were running a Windows-based application a few years ago, you had to use performance counters to monitor it. That was just the correct thing to do, but today not so much. Using performance counters means you are required to always have a Windows machine you have control over to monitor your application, which precludes you from using some of the more modern cloud and .NET features. We’ve fixed this by migrating to OpenTelemetry, an open protocol to collect metrics from your system.
Who looks after the architecture?
A year ago the teams were already able to decide the best way to implement what they needed to implement on their own. We did however have a single point of failure when it came to architectural decisions like what improvements to the whole system to pursue. This is no longer the case: we have a new head architect and a team of people who regularly meet to tackle these complicated issues and work on POCs.
Everyone’s voice is heard
Our last great achievement has to do with how we plan things. Previously the product owners would mostly unilaterally decide what each team would be doing. The team did have a say on how much time that would take and what steps needed to happen, but by and large the POs would decide what each quarter would look like. That is no longer the case since when we introduced the concept of PI plannings, where each and every person in the company takes part in this big process to decide what the next quarter will look like. This means that the teams have a chance to decide who is going to work on what feature and how, which has let us deliver more with less stress on the teams, which now have the time and motivation to do a much better job.
The strive for excellence
Does this mean that we are done tackling these complex issues? No, it doesn’t, and after all our ability to quickly see what needs improvement and to offer solutions is still key to this continuous improvement process. We can use the resources we have on the cloud in a more efficient manner to save cost and maintenance time, we can still clean up the more obscure parts of our code, we can continue to move towards more modern and flexible technologies like .NET 6 or containers and we can improve our planning process to make leaner and more open to everyone’s ideas. But in the interest of keeping morale high and giving everyone a positive outlook on the future, it’s important to recognize all of these gargantuan accomplishments we’ve achieved in less than a year.