Let’s talk about how Cove came about and what kind of projects you work on.

Before Cove, I used to work for a small web agency, but that eventually closed down, so I started my own company to take on new clients. My interest was more toward backend systems and technical solutions than a typical web agency approach. So the types of clients that I’ve approached are either industry-type companies that do industrial work or produce products. Then, I focused on production systems, such as order and warehouse management.

 

What made you narrow down your focus on that industry?

At the web agency, we were approached by some industrial companies with existing systems built with Laravel and PHP. Since we had a lot of experience working with WordPress and some other PHP custom projects and using Laravel to create various websites, we were able to help them. Through these collaborations, I gained a lot of experience working with these systems and industries.

 

What was your team-building process like, and what led you to outsource?

With the significant load of projects I was getting, I soon realized I needed some help with execution. I contemplated hiring people, but finding good programmers is difficult, so outsourcing is often a better solution. 

In my previous job at a web agency, I was responsible for hiring people. But, unfortunately, in Norway, if you want to hire good programmers, they’re usually employed, so you have to steal them from other companies, which is generally very expensive. So I would not be able to hire locally, at least for the projects I was working on.

 

How did you come across Redberry?

I was looking through the Laravel partner list and noticed Redberry there, but I didn’t immediately make contact because I was still unsure. Coincidentally, Guga from Redberry sent me an email wondering if I would be interested in collaborating with you guys, so we hopped on a call and went from there.

I hadn’t met any freelancers before Redberry; I found it very difficult to find people available for work; maybe I was looking in the wrong places, I don’t know, but it wasn’t easy.

 

What was a decisive factor for partnering up with us?

You were partners with Laravel, so that gave me confidence. The crucial thing was that I could look at the code written by the developer I would work with. I was allowed to see some of the projects and review the working process. That was the reason I decided this could be worth trying.

What are you paying the most attention to when looking at the code?

When looking at the code, I’m checking for consistency, namings of functions and methods, and ensuring that these things are consistently named. Then I’m also looking at the code use, the methods used, and if you are using the intended frameworks. Usually, what separates senior and junior developers is how well they know the frameworks. Finally, I’m also looking at the Git commit history to see that all the commits are atomic and short, so it’s easy to trace any bugs or figure out why the piece of code was written the way it was.
Besides, organizing everything in code is very important. There is a quote that goes something like this:

there are only two difficult things about programming, one is cache invalidation, and another one is naming things.

I find that very true. So trying to keep things in a logical place is very important. That’s a challenging thing to do – to write code in a way that flows naturally.

 

How did the partnership with Redberry develop, expectations vs reality? 

I’ve worked with outsourcing before, so I had some expectations. My previous experience went well initially because the company we outsourced had a senior developer work with us. However, the senior developer then delegated the tasks to junior developers, and those tasks ended up having more bugs and problems. So I was expecting this learning curve when I started collaborating with Redberry. But while working with Redberry, I could review the pull requests made by the developer and ensure that everything was within my expectations. I could also request changes if needed.

it was a little bit of learning and getting to know each other, but my overall experience [with Redberry] was better than I had expected.

How was the collaboration process with you and our team?

The way that we worked was that we would go through the project, I would explain what the project was about and how it worked, and then we would discuss what needed to be done. Then we would create tasks and delegate them to Giorgi or me. We had separate feature branches on Git and merged them into a development branch. We didn’t necessarily follow the standard Laravel code structure; instead, we tried to keep things to the domain level. 

 

Let’s talk a bit more about the project you worked on together. What was it, and where did event sourcing come into play?

The project we worked on was EDI software. We received order information from an e-commerce platform, connected it to the shipping provider, and sent them all the package information needed to generate a shipping label. We decided to go with event sourcing because the client knew they would need to create reports, but they weren’t sure what kind of reports, so we wanted to give them the flexibility a priori.

In typical software programs, you have a model with attributes that you can put into the database. But with event sourcing, we let go of the modelling and focused mainly on the events in the system. So, for example, an event would be when we received the order information; we would receive and store this information as an event in the database. So we aren’t reading the model directly from the database, but we are building the model based on the events we have received.

 

Why did you choose event sourcing over the traditional relation-based model for this project?

In most cases, I don’t think event sourcing is a good fit for projects because it’s more complicated. Building it takes a lot of time, especially if you are new to it. Usually, you’d better have a standard relational model.

The benefit of doing event sourcing instead of the traditional relation-based model approach is that we have all the information about what happened and when. So if we ever need to make changes or debug why something didn’t work, we can replay all the events that occurred.

Then we can stop the code there and read what’s going on. 

While it’s conducive for debugging, it’s also great for reporting. You don’t need to know what you want a report on before you build the system. Instead, you can build a system and later decide what kinds of reports you want because you have all the data to generate any report.
With traditional modelling, you usually need to know what kind of report you want so that you can log that data to generate reports. Since you can never go back in time, you must consider what types of events you are working with before you start working on a code.

 

How did you navigate the problem-solving process while collaborating with Redberry?

I had not worked on event sourcing before; my introduction to it was at the online Laracon, where I became interested. So it was a huge learning process for me as well. I did understand the core concept of it, but there were new kinds of problems, especially with how things are stored in the database was a little bit difficult because we had a lot of information about the events we were processing. So Giorgi and I spent a lot of time reading and figuring out how stuff works. We eventually figured out that we needed to write a normalizer and then reformat that.

 

What is the project’s current status, and what are your future plans?

Currently, the project is on hold because we are working on other parts. As for my plans, I want to build more software as a service I own instead of working on client projects. If I can get more software-as-a-service projects running, I might be interested in expanding, but until then, I’m pretty happy to stay small.