How did we met?
The cryptocurrency company needed help. More than two years earlier, they decided to create a subsystem to their software environment that would serve clients from a slightly different group than they had done previously. Their business was all to do with cryptocurrencies so it was a tricky domain, technologically-wise. They were already over a year into their development when they had an issue with the software team - they weren’t meeting the delivery criteria and the outcome wasn’t satisfying the business owners. Progress was far too slow and the team was already a few months behind schedule and nowhere near finishing up. The system in question wasn’t easy as it involved money exchange so the developers needed to fully appreciate how secure and stable it needed to be. Expectations of the application were high and, unfortunately, the production version being postponed didn’t influence the business well at all.
Problem source verification
We started small. We didn’t want to add to the client’s problems, we just wanted to help. We really liked the original idea of the project so we decided to offer a reasonable first step - an audit of the application which was currently being written. It showed some serious concerns, mostly regarding the level of testing implemented and the lack of any kind of activity tracking in the app. As we progressed to step two, we prepared an extensive code review with very specific recommendations. We knew how much money our client had already spent on the first system and we also knew that the final release had to be done soon. Simply rewriting the whole thing wasn’t on the table - there was simply no time. The system needed to work soon and, well, we did the only thing we could - we made it happen.
Speed of execution
After the review, there was no time to waste. We knew we had to build a team of programming titans. The project had some requirements that weren’t easy to meet. The technological stack was pretty novel so we needed to find developers of one of the most complicated and difficult programming languages there is and, additionally, one with a brand new asynchronous framework that nearly no one had used yet. In addition, we also needed senior developers. It wasn’t a case of writing something from scratch, which is a lot easier, the main objective here was to make what was already done much better in order for it to be able to service clients in a stable and secure manner. All of our teams were busy on other projects at the time so it wasn’t an easy task for us, but we managed to assign proper specialists to the task within days.
The team
We knew that time was of the essence so three developers joined the team that had been working on the system from the very beginning. We knew that simply swapping their team with ours wasn’t the solution as the transfer of knowledge would take too much time. So we joined forced and made sure we all had positive attitudes and ensured got on well together with members of the other team. One of the team members on our side was an IT architect - his role was to watch over every step that the team took and to make sure we were all moving in the right direction. Our priorities were to write unit tests and logs to cover as much code as possible so that releases were made safer and more predictable. There were also a few functionalities left before the final production release that needed to be added fast. As the architecture of the system was really complicated, the lack of tests and logs was a true danger to the project. When we have a live software on our hands as well as a system used by numerous clients exchanging information and capital through it, it is crucial to be able to fix any issue that occurs within minutes, or even just seconds. However, without proper tests and activity logs it’s virtually impossible. As a result, the app loses its credibility due to an excess of downtime and errors. We knew that the system safety was crucial so work needed to be done fast. We commissioned senior developers to write the unit tests which may sound strange to some, but it was the most prudent course of action at the time.
Challenges
One of the biggest challenges that our team faced in this case was working alongside previous app creators and trying to lead them towards a “more appropriate” way of doing things. They weren’t weaker developers than us, but they were simply led in such a way that, at the end of the day, just wasn’t sufficiently productive. A lot had to be changed, for example, the method of communication with the client. At first, the methodology used for team management was Scrum. Our team quickly realised that there was no time to actually implement Scrum correctly and be able to benefit from its values. The decision was made to simplify the process as much as possible, putting a lot of weight on fast and frequent communication with the product owner on the client’s side. Release driven development was introduced and this brought focus back onto the core value to the project. We also introduced a refreshed version of Demo, during which, the results of the work completed last week was presented by the team in such a way that it was engaging and attractive to the stakeholders.
Outcome and current status
The system is now live and fully functional. The team was able to provide a stable version of the application in the production version and substantially reduce the time required to verify the source of any errors and fix the issues. The application is currently stable for both individual and business clients. After some time, our team took over the project and is currently developing it, adding new functionalities and still improving its performance.
What do our team members say?
“Cooperating with the product owner on the client’s side is a pleasure. We know exactly what to do and aim to complete all tasks as quickly and efficiently as we possibly can. We make sure that our work is secure and never forget what kind of system we’re dealing with. I think this is the most important thing.”“I really appreciate this project because it has taught me how important it is not only to do good work, but to remember what the goal of the work is and also the business perspective, too. I think that a strong focus on the overall value is the glue that holds our team together.”
What do our clients say about cooperation with LEOCODE?
“We really enjoy working with the LEOCODE team. They were able to help us out right at the time when we needed a competent IT team with a high ownership culture. They adapted to our communication style which improved the progress of our work a lot. If you struggle with any kind of IT challenge in your company, LEOCODE is the perfect team to talk to" Dawid, CTO of the cryptocurrency exchange platform.
Conclusion
- Remember to choose the methodology of the project to meet its needs and goals.
- Don’t be afraid to ask for external code review and audits to verify the work of your team - it’s always good to know sooner rather than later if something is amiss.
- Make sure that both sides of the cooperation (the business owners and the software development team) understand each other well - if there is any misunderstanding at the beginning it is bound to cause problems further down the line.