Admyt on Outsourcing Software Development and Working with Legacy Code

Tired with coins, lines, and faulty pay machines, Jordan Wainer, an entrepreneur and innovator decided to improve car parking systems around the world. That’s the story behind Admyt, a solution providing a seamless shopping experience: simply drive in and enjoy your visit at the mall, hotel, or pretty much any place where you have to pay for a parking spot.

They have validated their idea by implementing their solution in 14 premier malls across South Africa and 6 live offices, with 6 more launching in October 2018. Their app has been already downloaded by around 30,000 users. As a business, they have set out to improve people’s lives bit by bit.

In the first part of the interview with Jaco van der Merwe and Devon Beynon we spoke about their business model and strategy, the future of car parking systems, and how the Polish market became their market of choice for the Admyt solution. In the second part, we discuss their most burning technical challenges: refactoring legacy code and outsourcing their software development. 

Devon Beynon COO, and Jaco van der Merwe CTO at Admyt 

Karolina Gawron, Monterail: Jaco, I know you’ve been a CTO at Admyt for a few months now. How did your adventure with Admyt begin?

Jaco van der Merwe, CTO at Admyt: It began somewhere back in 2015 when Admyt started. Back then, I was still working for another company—Protoclea, the guys who developed the license plate recognition system we use. Admyt approached Protoclea for an LPR solution that opens barriers at the malls. I was part of the team that worked on this solution for a little over two years when Admyt asked me if I would be interested in being more actively involved. I thought this an exciting idea.

Karolina: So what was the most compelling thing about Admyt?

Jaco: They think outside the box. This isn’t a solution that couldn’t have been done a while ago and the technology isn’t exactly new. But for some reason, everybody seems to have accepted that paid parking requires tickets and there’s nothing you can do about it. Admyt came around with a new idea and I thought that it was a great one. It challenges the norm of how we use daily things. And obviously makes everybody’s life better. No fuss, no standing in lines... Simple. From an engineering perspective, it’s nice to do something that improves people’s lives on a daily basis.

Get at-a-glance access to useful information like when you arrived, how long you’ve been in a centre, opening hours and more. Source: Google Play

Karolina: Jaco came on board when one of the most pressing challenges for the company was effectively working with legacy code. How did you find your bearings in that situation?

Devon Beynon, COO at Admyt: Jordan [Wainer], the founder of Admyt, lives in Sydney and there was a company there that initially built the system. It’s the same in any IT business: there are some assumptions and so we assumed that the system will work in a certain way and that was what we built and that got us going. Over time, you learn your lessons and come to understand that in reality things don’t exactly work out the same. We ended up with the code we basically have right now which is not perfect, but not bad. Then we made the decision to outsource to Monterail and have them take the legacy code over. Now we realize that there are things we could have done a little bit better, but we couldn’t just take two years of work and throw it away!

The challenge we’re facing right now is efficiency. From a coding perspective, the way the system works could be much better and faster. But I don’t think that coding as such was a big problem. It’s more about business needs and challenges we didn’t know existed back then. 

Karolina: So right now you want to refactor your code, right? How much time are you spending on this and how much on new features?

Jaco: It’s a mix-and-match of both. It’s kinda difficult because you want to push new features out and get people excited about the product, but on the other hand you’ve got issues that are burrowed deep and require refactoring legacy code which we have to solve first before taking on a whole bunch of new features. There’s a lot of the base things that can’t be just neglected. You can keep on adding features, but then it’s almost like hacking the system—as a result, you’re left with a monster application that has all kinds of features hacked into it rather than a polished product built atop a nice, solid foundation you can work with. The former just gives you more and more issues as you add new features.

So, to answer your question: it’s a balance of both. New features make more people sign up, use the app, and get people feeling positive about the product. We want to get through refactoring quickly in order to get to the nice part.

Karolina: Do you think it’s possible to avoid legacy code in the future?

Jaco: I think it’s a challenge in every software development company. You start with an idea and you have to communicate the problem. The way you do that with your development team needs to be very clear, but you cannot predict all the things you will encounter. I think that the best way to avoid this kind of things is to stay with the same team for as long as possible. Otherwise when there’s a whole new team, there’s a whole new way of thinking, different ideas… They have to pick up where someone else left and documentation is not always up to date. Documentation is a great idea in software development, but the reality can be far from perfect.

On the other hand, you can spend hours on documentation and know exactly what’s everything going to do and still navigate it to the wrong partner, leading to the the project taking two years instead of six months and the business ultimately shutting down… I think getting it perfectly right is something of a dark art. You must be really lucky to get it right the first time. Talking from my own experience, of course.

Yes, there are best practices, but you should stop to think why you’re doing what it is you’re doing. Let’s try and solve the problem first, and let’s try to avoid applying a bunch of patterns to it, because all problems are always somehow unique. There’s no simple recipe.

Karolina: So do you think that arriving at a point where you’d only work on new features is possible after working with one team long enough?

Jaco: I certainly hope so!

Devon: That’s something we’re pushing hard towards. We’re working to get the basics right to focus 100% on features. The one good lesson we learned is to think more. It’s key to this whole refactoring legacy code thing. You build code and you grow tech debt because it becomes a legacy code once it's written. So you build it and at some point you go back and look where all the gaps that we kinda missed are, or the bugs that maybe we left because we were busy building new features. You get into these circles where you build tech debt, then you go back to fix it, and once you do, you can carry on. But the fixing’s also gonna build some tech debt, too. There’s always gonna be something that you didn’t think about.

Jaco: That was definitely a lesson learned from the past: every now and again, go back and accept that we just need to fix some things before we get to the new stuff.

Karolina: How much of your development do you keep in-house?

Devon: From the development point of view we’re all set with Monterail. We do some local coding for server-related stuff, but all the work on the platform and the client-facing app is outsourced.

Karolina: In your opinion, what’s most challenging about working with a software outsourcing company like Monterail?

Jaco: I used to work for a company where we did everything in-house and outsourcing challenges you to communicate requirements properly. You have to be sure that what you intend to be developed, what’s in our heads, is also a picture outsourced programmers get. Another thing would be distance between the companies. Even though we’ve got Skype and Slack which shorten the distance whenever needed, you must be disciplined, it’s easy to get sidetracked.

Devon: We work on this all the time, as Jordan [the founder] is in Australia, Monterail is in Poland, we’re in Africa and we’ve got partners in America as well. We’re getting better at identifying what we should and shouldn’t say to stay efficient. Most times, we need to suck it up and work the long hours. It’s not an 8-to-5 job.

Karolina: Different companies decide on different ratios when it comes to in-house development vs. outsourcing. Do you think that one day you’ll move fully in-house or will you stay with a hybrid approach with some third party?

Jaco: We actually like the model of keeping the company lean and outsourcing as much as possible where we can and collaborating with other businesses in this process. The big business model in South Africa is not working. It’s difficult to manage. We’d much prefer working with a small Agile team and then outsource, and see where we can work with other teams. So there’s no plan to become a big conglomerate with the whole big in-house team. We’d rather work with other companies and carry on like that. I think it makes more sense.

Devon: The flexibility is kinda the key thing here.