Oleg Efrem

A ticket investigating software product for mobile operators that collects data from heterogeneous sources, correlates them to find problems and possible solutions, and automatically communicates the findings to customers and system owners. It reduces the amount of effort needed to find problems, shortening the feedback cycle. The system provides value for tens of millions of users. I was praised by the CTO as being a key contributor for securing the first contract, development, and delivery of the product to Vodafone group.

Our client had the problem of its test data growing to 2TB - 3TB a week but its routine to reduce the size of data without removing meaningful information was not designed for such volumes and thus was taking several days to run. We created a solution that would take no more than two hours, allowing time for other routines to complete over the weekend. The original quote was a development time from six to twelve months. I was given the task, together with a colleague, to have it ready in three. It was a very challenging task because of the specific database architecture, lack of documentation, and a DB with its own programming language. We had to learn the language and architecture, make sense of the data, find the best approach, and have the routine that would leave only 2GB - 3GB of meaningful data without affecting the functionality of other test systems and routines. We split the task, trying two approaches (deleting data and copying data). Copying data and replacing old entities altogether with new ones turned out to be the winning approach. We were praised specifically by the CEO of the 1,200-employee company.

Starting in 2010, when Scala was first getting its grip on the market, we ventured into adopting it with the team, calculating the risks, pros, and cons. Months after our first trial project, we decided to have all new code in Scala, shortly thereafter migrating our whole codebase from Java to Scala. It was an interesting and challenging journey, where we had at times to live with both Java and Scala and make it inter-operate at all levels up to the application server. The result was a codebase with 5x less code that is clearer to read, understand, maintain, and extend. Our calculations on the benefits it will bring over the possible risks proved to be right. The products we built were performing best among all the systems that our customers had.

I was hired to help the team split up the monolith Scala Play-based application into micro-services and refactor the codebase. The chief architect, who was one of the first developers of the app, praised the results of my work in a couple simple words: "I don't know how he does this, but every code he touches becomes beautiful." It was a reassuring experience that quality as a result of thought, research, and effort does bring results. I've always built code with the reader in mind, and my coding philosophy is that the code should tell you the whole story and be easy to read.