Essay on benefits of CV-Driven-Development

CV Driven Development

In 2016, Marek Kirejczyk, who was a VP of Engineering at Draftcode, wrote an article about Hype Driven Development. It became super popular in Poland at that time. For me, that was too early to realize why this topic was important because my experience was located around mature (ancient, actually) technologies, not the hyped ones.

Software is driven by fashion

In 2021, a huge part of our industry is still being driven by fashion/hype. So am I. We want to use the most modern techniques and tools. Even when there is some mature solution, which is ready out-of-the-box, many people (mostly developers) want to keep playing with new toys.

We want to learn new things

In parallel to this situation, many people think - the best way to learn something new is to get this opportunity from our employer - to use a new technology in client projects, which means - getting paid for the education. The popular analogy for this scenario is about a dentist learning on the fly when you’re sitting on a dentist chair.

And… there is nothing wrong with it. In the next paragraphs, I will try to share my thoughts on the benefits of this approach.

Hyped-inception

I wouldn’t like to discuss what the CV/Hype-Driven Development is about. For this, I strongly encourage you to read an article published by Marek Kirejczyk 5 years ago. It is still valid.

Podcasts, blogs, and conferences take part in a crime

What I realized in many conferences is that people started blaming so-called CV-Driven-Development and it became a famous joke being told from the stage during the conference speeches. This is a good way to get some chemistry with an audience, which is full of engineers. Speaker and audience may laugh for a while because they both understand the joke.

Most of us attended many talks, listened to many podcasts and read many blog posts before. In most of the projects, we are not using DDD, Kafka or fitness functions daily. We also do not work on the Internet or Behaviours, nor we do not consider Total Experience as a critical aspect of our daily work. Of course, these are perfect tools/approaches/strategies to solve particular problems. However, for the majority of software projects, these are not applicable. Still, the joke remains funny for us as some kind of “we are not using it in our project and the other ones are using it because they are CV-Driven”. In reality, many of these hyped projects really need these tools.

Where is the inception?

Laughing at CV-Driven-Development became hype itself. “Laughing” seems to be a hype. Pretty often this is just an easy sentence to be told to say “I am more conscious than the other people, who are developing the software by making CV-first decisions”. We like to continue with the “problem space -> solution space” kind of discussion. It gives us the ability to speak about approaching the specific problem of our client and designing a well-suited solution. Of course, we do that by applying the simplest methods and technologies ever, just to fulfil and slightly overcome the expectations of our client to help him/her realize that there is a great opportunity to grow after achieving the current goal.

Let me give you a few examples, that I was using in the past to feel smarter when I was not.

Example 1: Microservices and Actor Model

I spoke about microservices as the evolution of SOA and I was referring from it to Erlang’s actor model. I had some understanding behind that but today in 2021 I still do not have any commercial experience in using Erlang, Akka or Elixir. I also haven’t got PhD from mathematical models of concurrent computation. My thinking about it was very thin and not covered with real-life problem solving, which means - experience.

In this example, I wanted just to feel smarter.

Example 2: Domain-Driven Design

I was referring to Domain-Driven Design in many discussions. I read Eric Evans’ book and I started using Event Storming in 2017. Today, I use the Miro board for thousands of activities in my daily work and I consider visualization methods as one of the most awesome things in the world.

I even had an opportunity to work with a man, who was encouraging me to structurize the code in a “domain way”. It was in 2015. I didn’t even know if such a thing like DDD exists.

DDD is beneficial for everyone

Thanks to DDD, I was able to quickly understand the concepts of API design, separation of concerns, invariants and relations between applications/teams. That let me quickly realize how to design the APIs in a design-first approach where you start by understanding consumer behaviours and leaving the data structures at the last moment. It became super easy and natural, thanks to theoretical knowledge of DDD.

Today, I understand and use its concepts pretty often. However, as I haven’t been coding commercially since 2015, I do not know if I should consider my knowledge as theoretical or practical. For sure, I am not a DDD expert, especially not on a tactical level. However, I am ok to speak with engineers about it and to use DDD as some kind of prism when I think about understanding the software in general.

In this example, I just wanted to sound smarter but after some time it became useful in my daily work.

Example 3: Micro frontends

A few years ago, I had an opportunity to work on a project with more than 60 micro frontend applications (separate repositories), which were being used to build 1 final application from the user perspective. That was nice because we were given this opportunity just after ThoughtWorks set it as the “Trial” in Technology Radar. We were even asked to cover all the acceptance criteria of functional user stories in 100% by automated tests. Dreamland for quality assurance engineers and frontend engineers. In reality, frankly speaking, that was not easy to work with it.

ThoughtWorks Radar to steer your development choices

Today, micro frontends are in the “Adopt” section of ThoughtWorks’ Radar. After some time, in 2020, I was running discovery workshops. A few of our partners decided to go with micro frontends in their system. I was able to talk with them about many anti-patterns, which I and my colleagues faced a couple of years ago when it was at the beginning of its hype. Today, I do not have experience in “how to make micro frontends super useful” but I have a “how not to do micro frontends” kind of understanding. For sure, I still do now know how to organize functional tests (Selenium / Cypress) in micro frontends application.

In this example, I wanted to express my background, which was not super successful but over time it gave me a valuable point of view for the new initiatives, that I participate in. All the hypes, that you take part in give you a lot of value. I used to complain about it. I was able to appreciate it years later.

Complaining is a nature, that we need to get rid off

This example also shows that - we tend to be always complaining. When we work with a legacy-project then there is a reason for that. When we work with a hyped-project then there is another reason for that. I need to learn how to appreciate what I have.

Is CV-Driven-Development bad?

As in many cases - it is good and bad at the same time.

When we work on a client-financed project, we should aim for using technologies that we are experienced in. We cannot lie to our customers that we are experts at something and then use their budget for our education.

Of course, if a client is aware, that we will be learning this new hyped technology, but it still seems to be a great opportunity to make some breakthrough then it is good to go.

Honesty is the key here.

Choose Exciting Technology

Why we shouldn’t use mature technologies all the time? These technologies work and we can actually solve most of the problems by using them. There is a great article published by Lucjan Suski about it - Choose Exciting Technology (btw, Lucjan is hiring).

Besides what Lucjan wrote. I found a great analogy in climate change. Let me give you a definition of the difference between “weather” and “climate”.

The software development industry needs to grow

Weather refers to short term atmospheric conditions while climate is the weather of a specific region averaged over a long period. Climate change refers to long-term changes.

How can we use this as the analogy for CV-Driven-Development? I understand it as… it is usually not worth using hyped technologies. Especially it is not worth for our clients. However, if we want to change the world then we need to keep doing it. Using hyped technologies in many projects will raise the level of the technological median of the projects in the world. After a couple of years, maybe the single project will not gain from it - but the whole software development industry (probably) will.

It needs to happen with huge respect to our clients, investors, sponsors. Honesty, trust, spikes, quick idea verification and engineering experience are the first steps for enabling us to play around with the new tools to help our CVs become rich.

Your boss wants you to learn new technology

Do you remember that I wrote, “the best way to learn something new is to get this opportunity from our employer - to use this new technology in client projects, which means getting paid for education.”?

If you are an engineer and you want to learn something new then I encourage you to learn the first 10% on your own. Many people will be happy to pay you for the remaining 90%. From my understanding, the hope about having someone who will pay for 100% of the education is the thing that differentiates engineers, who are being trusted from the ones, who are still waiting for the opportunity to learn something new.

This is the starting point, which will enable you to take benefits from CV or Resume Driven Development.