Reintroducing engineering thinking in the development world

Image for post
Image for post

At Qonto, we strongly believe that the success of our company will depend on our capacity to grow people and develop their hard skills. For tech teams, it means developing engineers and engineering culture. This article is about how we try to do it at Qonto, by giving our developers the time they need to have real engineering thinking.

Imagine you have to build something complex, a car or a house, what would be your first move? Grab a wrench, a hammer and start building it? Or will you first take a pen, try to understand the whole complexity of what you will build, draw a schema, make a plan and only start the construction part once all the engineering problems are solved? I bet you’ll choose the second option.

All good engineer knows it: you should use the pen before the tool! And it’s even more the case when the system you are working on is becoming more complex. This is true when you are an architect, a car engineer or a web developer.

Indeed, when your company grows, your software complexity grows, your team becomes bigger, the potential consequences of introducing a breaking change becomes way more important. Very soon, a feature that once was pretty simple to ship becomes a real engineering challenge, and you need deep conception thinking before you start developing it.

Unfortunately, after having worked with a bunch of technical teams I often saw the same pattern happening again and again: developers are fed with features specified by a product manager and then asked to slice it and start developing it right away. No time for conception, only for delivery.

At Qonto, we are building a Bank. This is a real engineering challenge and having this kind of “counter-engineering” culture would be suicidal. That’s why we decided to define our own way of building features and this is the main topic of this article: how did we reintroduce real engineering thinking in web development at Qonto?

What happened to the engineering culture in web development?

Of course, there is a lot of good engineering thinking in web development, but the overall engineering culture in our world is way lighter than what we can find in “old industries” that we too often look down in our startup ecosystem. In my personal opinion, the root causes are two folds:

The negative impact of Agile Methodologies on engineering culture

Let’s be clear, the spread of Agile methodologies during the last 15 years brought a tremendous amount of value to the software engineering world, no question about that. Mainly because they offered an alternative solution to Waterfall project management that could be summarized as follows:

On the other hand, Agile methodologies gained its popularity based on the following concepts:

And the second step is where the problem lies. Because Agile methodologies drastically reduced the scope of the development work, it also completely got rid of the technical conception phase.

The classic Agile tech team will have the following behavior: during the ceremony, the team has 1 to 3 hours to understand a feature, slice it into user stories, story-point them and get ready to develop it. Right after the ceremony they open their text editor and start coding because they have a number of tickets/points to put on done.

And it always ends up the same: they start coding, they bump into technical issues they did not anticipate, it changes everything in the way they need to implement the feature, they restart from scratch, bump into another issue, etc… And the most dangerous thing is that we coined this kind of waste “iteration” when let’s face it, it is pure bad technical conception.

Hence, year after year, we created the conditions where developers are pushed to code first and think later.

Of course, this was not the original intent of Agile methodologies. For instance, the first wave of Agile, led by the Extreme Programming movement, was completely focused on engineering practices and make better engineers. You can have a look at the cornerstone books of this movement: “The Pragmatic Programmer” (Andrew Hunt, David Thomas) and “Design Patterns: Elements of Reusable Object-Oriented Software” (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) where the focus was on building clean and reusable code, alongside resilient and well-thought architectures.

But the emergence of SCRUM for instance completely changed the way Agile methodologies were approached and they became a simple management tool that got rid of engineering practices — mainly because managers were not able to understand any of these practices.

“School is useless, you only learn theoretical knowledge”

I don’t want to sound reactionary, but in the tech ecosystem, I can hear more and more people saying that going to university is useless because you only learn theoretical knowledge, until a point where it became a joke (see this “Silicon Valley” extract). Of course, you can become a good engineer without a diploma (and I saw plenty of good examples), but you cannot become a good engineer without strong theoretical knowledge and the ability to work with models.

Developing and mastering models is the key that allows you to quickly navigate between different complex situations and gives you the capacity to abstract your work. And this should not be a replacement for the “learning by doing” philosophy, but an addition. Years ago, my TPS sensei (read this article if you want to learn more about Qonto’s culture) told me about his theory of knowledge. Whether you want to learn something new or run an experiment to prove something, you always need three things:

Let’s say you want to lead an experiment to define Earth’s gravitational acceleration. You will need:

Now let’s say you want to learn how to do a proper service in tennis. You will need:

Same goes for code:

If we want to summarize, let’s look at it this way:

Image for post
Image for post

If you only think about “learning by doing” without models then you’ll end up having a pure “trial and fail” approach. As Bertrand Russel would put it, you’ll be nothing more than an inductivist turkey.

To become a strong developer you indeed need to learn by doing but also take time to deepen your theoretical knowledge. And of course, you need senior engineers that help you grow by giving you feedback.

How do we reintroduce engineering thinking at Qonto?

At Qonto, we try to approach things differently and we aim at giving time to developers to have some real engineering thinking. We do that thanks to something we call a dive-in, a phase that is mandatory in our development flow and consists of using the pen before coding.

What is a dive-in and how does it work?

What we call a dive-in at Qonto is a phase in our feature development process between the specification phase (what is the product problem we are trying to solve and what is the functional solution we propose) and the development phase (where we slice the work in small tasks and start coding).

Image for post
Image for post
Qonto’s feature development process

This phase is mandatory and is a time when developers only dive into the code base, think about the way they want to technically conceive the feature, about the implications of what they are going to do, answer all the problems they might face, go talk to other stack teams, do a POC if needed…

During this phase, they need to answer questions such as:

Image for post
Image for post
Extract from our dive-in Readme

Once the conception is done, the devs then push a merge request to the team explaining what they want to implement with diagrams, schema, images, pseudo-code or concrete examples of what modifications they want to implement (e.g which fields I am adding to a database with corresponding types). This solution then needs to be validated by the members of the team. Only once this process is done, then the developer starts coding.

This practice is for us a great way to:

So, how long does it take to do this technical discovery? Well, these dive-in are not timeboxed — each dev decides how much time they need to do a proper conception. To give you an idea a dive-in can last from 1 hour for very simple implementation to 2 weeks for complex work. We consider it as done only when developers are clear on the plan they will follow and are able to split their work into small tasks.

Of course, at first, implementing this kind of culture is not easy. You’ll face a lot of issues and resistance including:

But if you go this way with conviction it will bring you an enormous amount of value.

What are the impacts of introducing a dive-in phase?

Quality and speed

Of course, at first, this initiative might sound crazy in tech companies where time is at the essence, and where investing time upfront is often seen as a waste of time. But actually, you will win a lot of time because you will gain in quality… and velocity.

Indeed, after the introduction of the dive-in phase, we noticed a large decrease in reworks we had on features after shipping them. We went from a situation where a lot of features shipped needed to be reworked to solve bugs (rings a bell?) to a situation where when something is shipped, it most of the time works right-first-time. This, of course, increases your velocity (you don’t have extra work to do after the feature is done), improve your quality (fewer bugs and thus happy customers) and finally the trust in the work you do. Next target, having so much confidence in what we do that we get rid of the “do not push to prod on Friday” philosophy.

But it also has a huge impact on development time because when you have thought deeply about your conception before coding then… coding becomes quite easy! Here is the impact of dive-in introduction in our total development time on features after 3 months:

Image for post
Image for post
Total development time by feature (in days)

As you can see, it helped us to drastically reduce the time it takes us to ship a new feature, including the time of doing the dive-in: in 3 months, we almost divided by two this metric.

Bottom-line, giving time to your devs to do some proper engineering thinking is not just a philosophical stand. It has a strong positive impact on your business and on your customers.

Why you should care about it as a tech leader? Make people grow and feel proud.

Of course, this is great to see a direct positive business impact. But above all, it is a way for us to make people grow at Qonto and make the team passionate about its work. Instead of creating a dynamic where developers are pushed to ship code as fast as possible and fix it when it’s on production, you lay the ground for an environment where they can be proud of what they ship and trust the quality of their work.

Of course, everything is not perfect and we sometimes fall again into the trap of not investing enough time in conception — and sometimes the opposite. But as a team, we are learning on a daily basis how to do better technical conceptions and, bottom-line, how to become better engineers.

In our perspective, this is what will make a company prevail: invest in the people, give them the time and space they need to think about how they can become better at what they do, and they will make your company grow.

You want to work in this kind of environment? We are hiring!

The Qonto Way

Learning while scaling

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store