Software Engineering Efficiency in Action: Insights from Tsvetan Tsvetanov on Speed, Quality, and Cost

Table of Contents

Have you ever wondered how you could take your business to new heights?

At Camplight digital cooperative, we believe in fostering a culture of collaboration, innovation, and excellence in software development. We value our time, our clients’ and partners’ time. We strive for unsurpassed quality and efficiency.

Tsvetan embodies these values through his dedication to bridging the gap between business needs and engineering solutions, ensuring high-quality software delivery that exceeds expectations.

His involvement in mob programming exemplifies Camplight‘s commitment to collaborative problem-solving and mentorship within the development community. Today, we have the privilege of delving into Tsvetan‘s insights on aligning business and engineering, his approach to quality software development, and his experiences with mob programming and mentorship.

Hey there!

Yes, definitely. I first started with software development around 8th grade. My dad had a Mac II emulator installed on our Windows PC. I got a really old book about the BASIC language and started to experiment with things. It didn’t stick though.

The breakthrough came 2 years later when I got into game development. I was an avid gamer myself and had always dreamt of making games. This felt impossible at the time, but bit by bit I started ploughing my way through it. We gathered with some friends and started work on our first game: A space-based strategy where you developed your own solar system and fought against other solar systems. We didn’t get anywhere but this helped me land a job in a game development studio in Sofia.

Then I got disillusioned with the game development industry and switched to web development. This was fun, but the best part was that I could do it as part of Camplight. At first my main passion was related to helping people organize. I was the type of guy who always gave advice but rarely did the work 🙂 Fortunately, I realised this mistake. Now my passion is to first prove that I’m a really valuable contributor and then start mentoring people on how to work better together.

I shared most of my background above, so I’ll focus on core values. For me, people and humane interactions are the most important in a software development organization. Sadly, too many places treat people as resources. Cogs in a machine who have to be instructed what to do and pushed to do it. Sprint after sprint. And a lot of the current “agile” methodologies are covering that up.

Apart from that, people should understand how to drive quality in the product. Quality is not having a QA department or letting ChatGPT write your unit tests. On the contrary, quality is built-in the software development process through practices like Test Driven Development, Mob Programming and Continuous Delivery. Everything else is mediocre work.

I’ve always enjoyed responsibility. But not too much. Being a part of a cooperative let’s me have an ownership mindset without stressing over every part of the business because I know there are people I can rely on.

Another big reason is the fact that all of us are friends in Camplight. We enjoy working together, make grandiose retreats and share common values and interests.

Yes, I’ve been working with Akooda for the past 6 months. So far, it’s a great experience! The people there are really friendly and care about improving their process.

I’m a senior software engineer. My role hasn’t been tied up to any particular part of the system. The Akooda guys see me as someone who gets things done fast, so they rely on me to work all-around the system. Which is fun.

I’ve also taken the initiative to improve our processes as a team. Things like release cadence, building-in quality and working better together. People love that.

I think that’s the toughest part of every software engineer’s job. A lot of people just come into the industry and accept that business won’t be happy with engineering. And if we want to term ourselves “professionals” we can’t afford this friction.

And this friction is removed when:

  1. You always choose the solution based on the business need
  2. You build quality in and don’t wait for an approval from the business.

Yes, the techniques I use have been around for a couple of decades. Nothing new and fancy, but a person has to have the guts to use them. Because, for some reason, they’re frowned upon in the industry.

The main philosophy comes from Continuous Delivery. These are a set of practices that let you build software that’s easy to change. And this gives a big competitive advantage because:

  1. You have less bugs
  2. You can ship innovation faster

Continuous delivery is enabled by practices like TDD, Mob Programming and Trunk-based development. All of these have some learning curve, but are immensely beneficial in the long run.

Software Engineering
Continuous Delivery of Software

To be frank, I don’t like mob programming 🙂 But I think everyone should do it. Personally, I’m the type of guy who doesn’t like to be around people too much. However, software engineering is a team sport. And without mob programming, you don’t have a team. You have a bunch of people who compete about who’s going to finish their next Jira task first.

Mob programming forces the team to have focus and work together to achieve the needed results. It also makes you resolve whatever interpersonal issues arise and make the environment pleasant. Otherwise, you won’t have an effective mob.

Currently, I’m not doing it as much as I’d like to. However, this practice has changed my mindset. Now I rarely think about how to do my tasks first. I know that, even if it might be detrimental to me, the most important thing is to help the team achieve their goal. Frankly, no one has scorned me for being late on a task because I’ve helped X amount of team members.

Work in small steps. I find that lots of inexperienced engineers do programming in big chunks. Then they try to run or build the code and everything crashes. All of a sudden they’re in a big rabbit hole of possible causes for this crash. And it’ll take them a huge amount of time to get out of it.

My second, correlated advice: learn TDD. This will force you to work in small steps. It’s not a trivial technique to be mastered, but the sooner you get over it, the better. I bet that with it you’ll be more productive than a lot of seniors out there.

Again, practices like TDD come to the rescue. When you start to put quality first with TDD you find out, bit by bit, that you have 1) way less bugs to care about, 2) way less outages that wake you up at 3am, 3) can deliver features that took you weeks, in days. In this way, you have quality that drives speed of development and low cost of change. Of course, you can’t do TDD in isolation. There are other practices that can improve things even further.

Speed, Quality, Cost

We were mobbing the architecture for a big e-commerce provider in Bulgaria. It was me, the dev team, one architect and one PM. For several sessions of about 2 hours each we managed to design the new architecture and get everyone on board with it. Maybe this isn’t so innovative but it prevented the conflict between developers and architects standing in the way of improvement.

Well, I’ve already shared the misconceptions:

  1. That software development is an individual activity
  2. The false trichotomy of quality vs. speed vs. cost.

Working to dispel them is hardly just about the tools you use. I mean, I can explain TDD, mobbing and continuous delivery to you in a day. However, the process to integrate these practices inside an organization might take months. Mainly because of the human factor.

As I said, people are really sceptical about these practices. So a lot of the work should go in building trust with people first. What I do at the beginning is to prove that I’m delivering on promises. Even if I have to adapt to an inferior methodology. Then people start to appreciate my efforts and this makes introducing new practices way easier. After that I start nudging here and there. Trying a bit of TDD, trying a bit of mobbing, pushing people to review PRs faster and not to leave undeployed source code. When I see enthusiasm about a particular effort I double down on it and support it. Then, when it’s fully implemented, I move forward.

I also share a lot of articles and books on good practices, so people can understand them themselves and become more eager to try them out.

Mainly I do TWO things:
On the one hand, I constantly share articles and books on topics which I find valuable. And I try to discuss them with people.
On the other hand, I try to show an example and create a space for people to try out new stuff.

Well, this greatly depends. If the team is doing mob programming full time, you don’t need anything else.

Otherwise, people should start to get into the habit of putting the team first. This is done by prioritizing PR reviews, always being available for the team, making sure code is deployed frequently. Communication and coordination should also be transparent. In Akooda we have the great practice of discussing things in public Slack channels separated by topic. This allows us not to be blocked and to find information with ease.

There are TWO lessons:
First, quality is important. Don’t overlook it to get a false sense of speed.
Second, before you improve the process, prove that people can trust you. I’ve wasted so much effort on improving teams where people see me as the guy who gives a lot of advice but does little.