Essay on benefits of CV-Driven-Development
CV Driven Development
In 2016, Marek Kirejczyk, VP of Engineering at Draftcode, wrote an article about Hype Driven Development. It became super popular in Poland at that time. It was too early to realize why this topic was important because my experience was around mature (ancient) technologies, not the hyped ones.
Software is driven by fashion
In 2021, a huge part of our industry is still driven by fashion/hype. So am I. We want to use the most modern techniques and tools. Even when some mature solution 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 famous analogy for this scenario is about a dentist learning on the fly when you’re sitting on a dentist's 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
I realized in many conferences that people started blaming so-called CV-Driven-Development, which became a famous joke being told from the stage during the conference speeches. This is an excellent way to get some chemistry with an audience of engineers. The speaker and audience may laugh for a while because they understand the joke.
Most of us have attended many talks, listened to many podcasts, and read many blog posts. In most projects, we do not use DDD, Kafka or fitness functions daily. We also do not work on the Internet or Behaviours nor consider Total Experience a critical aspect of our daily work. Of course, these are perfect tools/approaches/strategies to solve particular problems. However, these do not apply to the majority of software projects. Still, the joke remains funny: "we are not using it in our project, and the others are using it because they are CV-Driven”. In reality, many of these hyped projects need these tools.
Where is the inception?
Laughing at CV-Driven-Development became hype itself. “Laughing” seems to be a hype itself.
This is about saying: "I am more conscious than the other people developing the software by making CV-first decisions”.
We want to continue with the “problem space -> solution space” discussion. It allows us to discuss approaching our client's problem and designing a well-suited solution. Of course, we do that by applying the most straightforward methods and technologies ever to fulfil and slightly overcome our client's expectations to help them realize there is an excellent opportunity to grow after achieving the current goal.
Let me give you a few examples I used 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 to Erlang’s actor model. I had some understanding behind that, but in 2021, I still do not have any commercial experience in using Erlang, Akka or Elixir. I also haven’t gotten a Ph.D. in 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 one of the world's most awesome things.
I even worked with a man encouraging me to structure the code in a “domain oriented way”. It was in 2015. I didn’t even know if such a thing like DDD existed.
DDD is beneficial for everyone
Thanks to DDD, I could 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. I am not a DDD expert, especially not on a tactical level. However, I am okay with speaking with engineers about it and using DDD as a prism when I think about understanding the software in general.
In this example, I just wanted to sound smarter, but it became useful in my daily work after some time.
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 after ThoughtWorks set it as the “Trial” in Technology Radar. We were even asked to cover all the acceptance criteria of functional user stories 100% by automated tests. Dreamland for quality assurance engineers and frontend engineers. In reality, that was not easy to work with it.
ThoughtWorks Radar to steer your development choices
Today, micro frontends are in ThoughtWorks' Radar's “Adopt” section. After some time, in 2020, I was running discovery workshops. A few of our partners decided to use micro frontends in their systems. I talked with them about many anti-patterns, which my colleagues and I 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” understanding. I still do not know how to organize functional tests (Selenium / Cypress) in micro frontend applications.
In this example, I wanted to express my background, which could have been more successful, but over time, it gave me a valuable point of view for the new initiatives in which I participated. All the hypes you take part in give you much 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 complain all the time. When we work with a legacy-project, there is a reason. When we work with a hyped project, another reason exists. I need to learn how to appreciate what I have.
Is CV-Driven-Development bad?
As in many cases - it is good and bad simultaneously.
When we work on a client-financed project, we should aim to use 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 knows we will be learning this new hyped technology, but it still seems to be an excellent 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 solve most problems by using them. There is a great article published by Lucjan Suski about it - Choose Exciting Technology.
Besides what Lucjan wrote. I found a great analogy for climate change. Let me give you a definition of the difference between “weather” and “climate”.
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.
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 since it is not worth it for our clients. However, if we want to change the world, we must 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 will.
It must 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 want to learn something new, I encourage you to learn the first 10% on your own. Many people will be happy to pay you for the remaining 90%. The hope of having someone who will pay for 100% of the education is the thing that differentiates solid engineers 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.