I started Infinum with Matej and have been running it as CEO for the past 16 years. A CEO’s job is many things, but the end goal is pretty simple–to make the company win. Winning can mean whatever you want it to mean. Getting a certain client, growing to a certain size, selling to a larger company etc.

Over the years, things have changed for Infinum. We’ve always had the goal of building excellent digital products for clients that drive business results.

With that, we’ve had great success. The business is strong, profitable, and on a stable growth tangent. We grew from 2 people to a 330 person strong global consultancy in a couple of years.

But also, we’ve ventured into other paths. We spun off and created other companies (like Productive), brands (like Flavorific) and created joint ventures (like Porsche Digital Croatia).

We’ve also invested in startups like P3 mobility (robotaxis), Rentlio (SaaS for hotels), Nowports (freight shipping), and CircuitMess (STEM, me personally).

Since their “humble” beginnings as a 120-people local web and development agency called TamTam in 1996, today DEPT is a globally recognized one-stop shop for digital solutions with 1500 people, 100 shareholders, and 20 integrated agencies.

Co-founders and brothers Bart and Paul first set out on their international adventure in 2015 and started laying the foundation for the DEPT of today and unraveling the hidden demand for agencies that handle the full scope of digital initiatives from a single point of contact.

Ever since, they’ve pursued new companies to acquire—and they aren’t planning to stop, regardless of the global pandemic.

I sat down for a two-guys-in-a-bar type of chat with Bart Manuel, co-founder of DEPT, to find out how they’ve approached the COVID-19 chaos, what their plans for the future are, and what they think businesses around the world should be doing.

Just drums, TamTam drums, which are like long-distance communication. In 1996, you had to explain to people what is the internet, and what you can do with it. Oh, you really can visit a website, and there was a lot of magic in that.

So we ran that agency and built it organically. But it was pretty much a national, Dutch agency, focused on our home market and based in 2-3 cities in the Netherlands. We grew that organically until around 2013, 2014. We then wanted to set out on an international adventure, shift gears a little bit.

In 2015 we started on a journey that eventually led to the foundation of Dept and now here we are, 5 years later.

We’re seeing larger traditional companies like WPP and Omnicom all publishing large cuts, in terms of either salary or people, so obviously, they’re struggling. Specialized agencies, we’ve heard a large variety of stories. I think it’s mainly dependent on your split in the client segment.

Fortunately, Dept always had a great diversification, which means we suffer some, but not too much. We’ve been continuing to hold conversations with all sorts of agencies, both in Europe and the US, and we see various degrees of optimism. We’ve actually seen an acceleration in the ability to hold the initial conversations because it’s totally acceptable to do this via Zoom, people have more time available so are quite open to conversations. Everyone is more efficient.

There are two things holding us back a little bit. Obviously, in the first month, month and a half, we’ve had to really look at our cash flow and debt governance, etc, that would be a difficult time to attract cash needed in order to close a deal. Now I think we’re sort of past that stage, so I think it’s a good thing.

The other thing is that we spend a lot of time on a personal level with the entrepreneurs and sellers of the agency to make sure we build a trusted relationship. And as good as Zoom is or Google Meet is, for us, it’s adamant that we need to be in the room, in the restaurant together, with the people, with the founders to really build that.

We’re going to do a lot of things differently, we’re going to do a lot of things online, but we’re still going to travel to make that connection and build that relationship. And that’s something that’s just not possible right now.

Especially because our main focus pre-COVID was and still is on the US. We’re building the initial relationships but the true moves we can only make when things are opening up again. But what’s really positive in the US is that there is endless optimism and opportunism in entrepreneurship where no matter how bad the situation is, they always bounce back.

We had the same experience here. Obviously, the initial reaction was a bit of a shell shock, and in the first couple of weeks, we’ve seen the biggest shifts. Big clients in travel and airlines, pulling all the work. You see it happening, and you think everything is falling apart. But after that first shock things stabilized pretty quickly.

Just as you, if you’ve invested in your client relationships and if your clients aren’t going anywhere, then things just continued. And we’ve had lots of very good reviews on our ability to deliver, continue to deliver from a work-from-home situation, especially productivity and creativity has been going up, lots of energy and ambition.

We are seeing that collaboration is much better in this situation than it was before, so that’s a good thing.

Because collaboration gravitates towards the offices, right? We have more than 20 offices throughout Europe and the US. But you usually collaborate with the people around you physically, but the good thing is, since there’s no one physically around you, all of the sudden the barrier to collaborating with someone in Rotterdam or someone in the US, it’s the same barrier.

In terms of keeping the same level of productivity in the long run, I think working from home all the time is mentally tough for most people, so that’s not going to work. What we’re working towards is the mixed mode, where people will have lots of more autonomy on how and where they want to work: From home, from a cubicle, or open space.

We’re also exploiting the existing social network–the relationships that you’ve built, just squeezing the last bits out of it.

But the thing that we don’t do now is build new relations, new connections. Onboarding the new employees to the company, to the culture. Doing that online is really, really tough.

I mean, how do you build trust and meet new people? That’s difficult. So inherently, I think the business will become a little bit more local. Within the Netherlands, it’s easy to collaborate with the client, I can just go to the Eindhoven office and find people there.

In terms of finding new clients and building business, we’ve been doing quite well in the last two months. I would say, very good. Much better than we initially expected two months ago. So yeah, maybe even for us as well it would be structurally better to find clients online only and to start doing business with them.

But still, in the new normal, you’ll lose a little bit of dynamics, let’s put it that way.

Yeah, you have a little bit of that. You’ve been infected with the American virus. The good one.

We need to realize that 5-10% of the economy is gone and I don’t think it will return easily in the coming year, year and a half. Especially in the hardest-hit sectors, it’s going to be tough. We need to adapt. One development that I specifically wanted to mention, it’s quite interesting, we see an acceleration in clients that want to accelerate their digital transformation.

I know everyone has been using that word, and we’ve been avoiding it, but the big realization for everyone is if you’re digital, you’re a winner. If you’re not digital, you’re going to be left behind.

So we’re shifting our focus from the sectors that are obviously going to have a hard time and focusing on the businesses that are going to be good. And focusing more on building a digital business, as opposed to maybe a new campaign or new marketing or content.

Let’s focus on the business first.

Because everyone uses it, it might be a little snobbish of me, I don’t know.

One realization we had recently, we were saying to each other up until a few months ago let’s not talk about digital transformation, or maybe let’s not talk about digital anymore because everything is digital.

Now we realize, due to COVID, a lot of businesses have been hit really hard, even the digital flagship cases who might have even 80% of the revenue coming from traditional high-street retail and only 20% online. They lost 80% of the business.

So our realization is that digital transformation is not done at all, there’s so much work to be done in so many businesses, especially B2B and supply chain integration. That’s where we’re going to be focusing our attention in the coming time.

I find it difficult to predict, but we’ve always diversified our industries, services, and geographies. Now’s the time to benefit from that, where we can rebalance things if we’re smart about it. The good thing is that you don’t have to look that far into the future, just make sure you adapt along the way quickly and then figure out where that leads us.

We’ve seen some huge drops in digital marketing, performance marketing, SEO, etc. We think mainly because we had some really strong clients, travel agents, airlines, etc. that were doing a lot of work there.

We don’t move out of digital marketing because we’ve lost some business, we’ll stick to it, but we’ll refocus their attention as well, on the industries that are now going to be pushing harder.

I think it’s good to realize and to make sure we keep caring for the less privileged people. If you were privileged to have a cleaning lady in your house and now she cannot come, keep on paying her, right? I mean, it’s the simple things.

There are people who are going to get hit really really hard, who don’t have any income or social support to fall back upon. I can’t think of how it must be for hundreds of millions of people around the world that are in a really dark place. It’s good to realize that we are extremely privileged.

Doing your thing, learning from that, and making sure you care for your business and your people–it’s the least you can do.

In the past, I’ve written about technical debt, and how it’s an all-too-common problem with software development projects. In a nutshell, the basic concept of technical debt is this: You build technology, but as you cut corners or optimize for delivery speed, you incur future costs that you’ll have to pay off eventually—or your project will go bankrupt.

Technical debt is a lot like taking out a 20-year bank loan to buy a house because you don’t have enough cash to cover it. You know you’ll end up paying more for the house in the long run, thanks to interest, but you’re okay with that. You’re willing to pay more to move into the house today.

So, how can you pay off technical debt and resolve these problems once and for all? One option is refactoring. Refactoring is the act of cleaning up your code, making it better and easier to read and maintain.

It’s the technical equivalent of reorganizing your closet. You’re not necessarily changing the contents of the closet—you’re just streamlining and putting things in their proper place. This makes it easier for you to quickly find what you need when you need it.

But how exactly does refactoring work? What’s the best way to approach it?

It seems as if every time a software developer takes over an existing project, they say something like, “This is the worst code I’ve ever seen. We should just delete everything and start from scratch.”

Maybe there aren’t any tests, the code style is out of whack, the libraries are outdated or it’s combination of all of the above.

Software developers like to play with the latest and greatest technology. In large part, that’s why they’re so passionate about their work. Because a software developer holds his craft in high regard, he or she doesn’t like to work on old, crappy tech.

But if you look at this from a business stakeholder perspective — chances are very slim that you’ll ever get the budget and time to do the BIG REWRITE every engineer is dying to do.
There are also other risks to the BIG REWRITE. For one, you basically lock up all your resources for a certain amount of time. If X months is your estimate for finishing the rewrite, you effectively don’t produce any new value to your customers for X months.

Even worse, what usually happens is this:  X months turns into 2X months. Joel Spolsky wrote about this ages ago —never rewrite your software.

So, what can you do?

There’s a popular 90s British sitcom called “Only Fools and Horses.” In the show, a character called Trigger (nicknamed after a horse, mind you), is a street sweeper. In one particular sketch, Trigger talks about how he’s had the same broom for 20 years.

When Rodney asks if he’s actually swept any roads with his 20-year-old broom, Trigger says, “Well, of course! But I look after it well. We have an old saying that’s been handed down by generations of road sweepers: ‘Look after your broom.’ And that’s what I’ve done; I’ve maintained it for 20 years.”

He then holds up his broom to show his friends and proudly proclaims, “This old broom has had 17 new heads and 14 new handles in its time!”

Baffled, the waiter asks, “How can it be the same bloody broom, then?” Trigger pulls out an old photograph of himself holding his beloved broom. He responds, “Well, here’s a picture of it. What more proof do you need?”

In ancient philosophy, this is also known as the Ship of Theseus (Theseus’s paradox) – if a ship (or any other object, for that matter) has all of its components replaced, is it still fundamentally the same ship?

So, what about a software development project? If you replace every single component of a software solution, is it still the same solution? Yes— but it will be a much-improved solution, as long as you take the right approach.

So, what is the correct approach to refactoring large, legacy systems? It all comes down to replacing smaller systems inside larger, running, systems.

In other words, you should build out a new framework and new concepts inside the existing, already running, application. Construct any new features that you build with this new framework, and try to use the old, crappy parts of the system as little as possible. If you have no other choice, create bridges to the old code in a way that will be future-proof.

Much like Trigger’s broom, you’re replacing the old, worn-out parts with more functional parts to ensure the solution is well-maintained. Remember those wise words passed down from generations of street sweepers: “Look after your broom!”

As part of this process, it’s important to continuously deploy this code, test it and have users use it in production. This is very different from the BIG REWRITE because we’re constantly battle testing our new code, hardening it and creating production-ready code.

So, we’re not just writing code with a million bugs that will be uncovered once we do the BIG LAUNCH after a year of work. We’re creating new code day after day, and deploying that to production regularly.

If you use this refactoring approach, this is how things will unfold over time: Your codebase will start out with 100% old shitty code and 0% new shiny code.

As time goes by, you’ll implement new features but using only new and shiny code. So, at this point, you have 90% old crappy code and 10% new shiny code.

As you keep doing this for all new features, you’ll eventually reach the tipping point where there’s more shiny code than crappy code. You can then pull off the BIG REWRITE, which at this point is basically eliminating the rest of the cruft.

Of course it can! In fact, we pulled it off in 2016 for the core application powering  Productive, a spinoff business born out of Infinum. We started off with a dated codebase that I personally wrote most of way back when.

The team took the Trigger’s broom approach, running both systems in parallel, and migrating parts of the architecture as they went along. In other words, they were slowly replacing those old, beaten-up broom parts with shiny new ones.

We strategized with users by redirecting them to the old parts of the system until they were rewritten completely. We ran two parallel JSON APIs until we didn’t need the old one anymore.

We chopped off small pieces of the old Productive here or there and extracted it to different microservices. We built the entire frontend on a completely new tech stack. Of course, the specs changed along the way, based on the business or user expectations, and that was fine. We weren’t stuck in rewrite hell, and we were shipping to production all the time.

Like Trigger’s beloved broom, we now have an application that’s basically the same from a business perspective — it’s still called Productive, and it still does the same thing (manages your agency workflow)— however it’s well-maintained and greatly enhanced.

Today, there’s not a single line of code in Productive from that old and dated codebase that I wrote. And believe me, this is a good thing— because I wrote pretty shitty code compared to today’s standards.

The next time you take over a dated or legacy codebase, and your inner instincts start saying, “Let’s just rewrite all of this,” try to change your mindset.

Ask yourself, “How can I add value, piece by piece, and replace certain parts of it, to make sure it will get better and better over time?”

It’s just like that old saying: “How do you eat an elephant? One bite at a time.”

(But please, don’t eat elephants. They’re extraordinary animals.)

You often hear stories from unhappy programmers who work on code that’s hard to maintain because it was written in a hurry.

On the other side, managers are stuck chasing deadlines and clients need everything done as soon as possible so they can reach a particular business objective.

How do you reconcile these two sides and produce software of sufficient quality but in a reasonable time?

Nowadays, if you need $100,000 to buy an apartment and you don’t have $100,000, you go to the bank and get a loan which you will be returning for the next 20 years.

After those 20 years, with an effective interest rate of, let’s say, 6.10 percent, you will pay off about $170,000 — because of the interest rate, of course.

You’re OK with that, as you effectively pay the price of buying the apartment now and not in 20 years when you might have saved enough money to buy it in cash.

So to have something today, you are willing to pay more in the long run.

When you work on a software project, you can do certain things well, or you can do them fast.

Every time you sacrifice quality for speed, you incur something in your project called technical debt.

When I say quality, I don’t necessarily mean the quality of what the user perceives, I’m referring to the architecture of the solution. I’m not talking about the facade of the house; I’m talking about the foundations on which it was built on.

The main influence of technical debt on a software project is that it makes the project harder to maintain. Introducing new functions takes longer and you are generally slower at everything.

Every time someone says “Just slap it together so it works” and doesn’t choose the best architectural solution, they incur technical debt on the project.

Getting into technical debt is not necessarily a problem on its own; the problem is if this technical debt is never “paid off”.

Technical debt is paid off by code refactoring. Refactoring is the process of changing an existing program code internally or rewriting it without changing its functionality or external behavior (the behavior which is seen by end users).

You do this so you can maintain that code and introduce changes more easily, and more quickly in the future (that is, to pay a smaller “interest fee”). Refactoring is like cleaning your closet. On the outside, everything is the same— the same clothes are inside the closet. However, if you fold and organize the clothes better, the next time it‘ll be easier to find a certain item.

You won’t need half an hour to get dressed, and you won’t turn the whole closet upside down while doing it.

Often organizations avoid refactoring because they don’t recognize the value of it. And they often don’t recognize the value because refactoring doesn’t provide any visible and obvious benefits.

The application does the same thing before and after a refactor, so why waste time (= money) on refactoring at all?

But you should invest in refactoring. If you don’t periodically pay off that debt, it will just accumulate, the project development will get slower and slower and, in the end, you will go bankrupt.

Every project contains a certain amount of technical debt. This is normal and does not represent a problem.
Having to pay $1,000 / month is not a problem if you earn $7,000 a month. But, if you have a $4,000 loan and earn $5,500 per month, that’s a problem.

It’s like in the real world — if you accumulate technical debt long enough, you will face technical bankruptcy. Technical bankruptcy means that you will probably have to rewrite the whole application from the beginning because the code is simply so bad that you can’t even work on it, let alone to refactor it.

You wouldn’t be the first or the last in the world to do that. Joel Spolsky wrote an article a long time ago about Netscape rewriting all of their applications. The reason was a large amount of accumulated technical debt and as a result, in the end, they had to close down.

I would define a technical manager as a person who takes care of both the business and technical aspects of a project.

They are people who understand how something should be implemented technically, but they also understand the underlying business dynamics of the project.

This person has to decide when the project should raise technical debt and when it shouldn’t.

In the end, here are several things that should be kept in mind when making these decisions:

I believe that technical debt is something that should be controlled and planned. You shouldn’t be careless about it because in the long run it may turn into a disaster.

The business side of the project will be unhappy because features are not created fast enough and it takes a lot of time for programmers to implement some minor things.

On the other hand, programmers will be unhappy because they constantly have to struggle with bad architecture instead of doing creative work.

For a while now, we’ve been aware that Android development takes longer than iOS. We have the metrics to prove it, and it’s about time we show them.

If you’re developing a mobile app on both iOS and Android, you’re bound to notice at one point that Android development simply takes longer. We’ve also noticed that, but instead of solely trusting our gut feeling, we’ve decided to pull out some real stats to prove it.

We extracted numbers for 6 projects we’ve done in the last year and a half or so. The projects were chosen according to the following conditions:

We measured the following parameters:

We pulled the information on the lines of code (excluding blank lines and comments) with cloc.

The takeaway here is – you write on average ~40% more code on Android than on iOS. A lot of this code is auto-generated – but it’s still code, and it needs to be read, debugged, and maintained.

Also, the quantity of code you have in your project is bound to be a lot larger if you’re using a modern and clean architecture approach in structuring mobile apps.

By that we mean something that separates the presentation layer from the business logic, like MVP on Android or VIPER on iOS.

In that situation – having more lines of code is actually good.

We pulled the information on the hours of work for each of these projects from Productive.

The takeaway here is that, on average, you spend ~30% more time working on Android than on iOS projects. As you can see in our table, sometimes the difference can be much bigger and sometimes much smaller, but, from our experience, the median value is around 30%.

We’re not inclined to believe that this has anything to do with the quality of engineers on any of the platforms, as our team is equally great on both platforms, and our HR process doesn’t discriminate when hiring for either position.

That’s a very good question. We’ve been speculating about this for a long time, and what we’ve managed to figure out is that it’s a combination of a couple of factors:

When we started doing iOS and Android development on a work for hire basis, we based all time estimates on the assumption that iOS and Android development take the same amount of time.

We abandoned that premise about two years ago, and today we take into account 20-30% more time for Android for all the estimates we do.

That means that if we estimate an app at 500 hours to be built for iOS, we estimate it (and charge it accordingly) at around 650 hours for Android.

What’s good here is that the trend is changing. The tooling for Android, which we covered here, is getting so much better, that in the future this Android tax will probably go down. Only metrics will tell.

Of course these metrics can’t possibly convey every possible scenario and problem you have while building software. But what we wanted to say here is that, generally speaking, Android takes longer.

Thanks to my colleague Ivan Kocijan for his help with the data preparation for this article.

Yesterday Apple announced two new phones (boring), a new smartwatch (mildly interesting) and old people playing rock music. They also introduced a payment system that could have a deep impact on the payment industry.

The system is called Apple Pay and it does some things a bit differently from existing mobile payment systems by leveraging Apple’s existing infrastructure. This includes a vast number of existing credit card numbers already registered with iTunes, TouchID – the fingerprint sensor and the Apple Watch.

According to the information presented in Keynote and other stuff floating around the Internet, if you want to use Apple Pay for mobile payments, it works something like this:

What’s not so obvious from the get-go is that Apple actually improved the security of credit card transactions with Apple Pay, as you don’t have to hand over your card to the cashier and use actual card numbers (you use something called Device Account Numbers).

To do this, they needed to achieve a new way of working with issuing banks, acquiring banks and credit card networks which is actually better than what we have now.

Don’t think so. As it seems, only cards issued by Visa, MasterCards and American Express, and from a couple of selected US banks will work. Obviously, the list of banks/credit card networks should grow in time, but, for the time being, this just means that not every Visa, Master or American Express card will work. It probably has something to do with the additional security layer described earlier.

The new phones (finally) have a NFC chip. You’ll be paying in stores by merely placing your phone next to a contactless terminal and then confirming the transaction with your finger on the Touch ID.

Contactless terminals aren’t a new thing. They’ve been around for some time now, but mostly in Europe (predominantly in the UK I would say).

What’s also cool here is that, if you have an Apple Watch, you can place it near the terminal and pay with the watch without taking out your phone.

This is something I’m not very sure of. From the looks of it, the readers look like standard contactless POS terminals. On the other hand, they specifically list available stores on the website, so I’m not sure whether it’s possible to carry out payments in other stores that accept contactless payments, but are not in cahoots with Apple. I’m thinking – no.

This is where it gets interesting. Developers can use Apple Pay to integrate payment in their own apps. Where previously you had to develop special screens for users where they would enter their credit card details – now you hand that responsibility over to Apple Pay.

Also, when I first heard about this, my initial reaction was: ”Ok, but what about In-App Purchase?” Since Apple takes a 30% cut for every IAP, and (if we were to believe Tim Cook) they won’t take a cut with Apple Pay, we basically have two competing payment systems on the same platform and one of them leaves you 70% revenue.

Here’s the official info from Apple on this:

It doesn’t say anywhere what happens if you try to sell Viber stickers via Apple Pay. Will your app be banned? Probably yes.

Now, there are all kinds of potential “what ifs” here. What If I’m buying a book? I should obviously use IAP… But If I’m buying a digital book from the same merchant – Apple Pay? What if I’m buying a physical book with a digital copy?

What if I’m boosting a Facebook post? Virtual goods – yes/no/maybe? Apple will never make Facebook give them 30% of their revenue, but Facebook would surely use Apple Pay for this sort of thing, and leaving it out is not a great decision from a user experience standpoint.

It’s kinda messed up, and I don’t think Apple will want (in the long run) to have two very similar payment systems existing.

Apple gives you a couple of options. I like Stripe, but there are also others.

There’s no mention of the watch itself having a fingerprint reader (I’m fairly certain it doesn’t). Getting your phone out of the pocket to pay with your watch is stupid. But having a payment go through the watch without the fingerprint isn’t really the same level of security, so I’m not sure how this works.

This is obviously rolled out only to the US for now. Following how Apple typically works, I think it should be available in other parts of the world in a year or maybe more.

The terminals look like your typical contactless terminals. But again, the system works fairly differently from traditional credit cards so we’ll need to see what happens here.

Payment systems are a chicken and egg problem. You need merchants to get users using your payment system, but you also need users to get merchants motivated for investing in infrastructure.

Also, payment systems are heavily regulated, so issues with local regulation could creep out of the woodwork. I wouldn’t be surprised if 2-3 years would be a normal time frame for some countries, or even if Apple completely gave up on certain territories. Google Wallet still isn’t implemented everywhere.

But the main takeaway from all this is that the new improved checkout flow will certainly yield more conversions. I’m talking about drastic increase in sales here.

Basically – you’ll sell more stuff in your mobile app simply because people won’t need to enter their credit card details anymore.

What this also means is that more native e-commerce applications will be showing up. What was previously a web app will now probably become a native iOS app.

The reason is again simple – if your e-commerce application is a web application, your customer will need to re-enter their credit card details, but if it’s a native application with integrated Apple Pay – it will be a one-tap process.

Also, rest assured Apple will bring this to your Mac in the next iteration or the one after that. Just as soon as they iron out a secure user experience. So after that – you won’t have to punch in your credit card numbers while browsing on a desktop computer any more.

All of this could be potentially huge.