David attended three conferences during the MiXiT 2022. He shares his feelings with us and reveals the topics covered: geopolitical challenges of digital infrastructures, agility et egoless programming !

Geopolitical issues of digital infrastructures

This first conference, given by Ophélie Coelho, focuses on the geopolitical issues of digital infrastructures.

Today, everything is geopolitical. Digital infrastructure is no exception. But how much? To what extent does infrastructure represent a vulnerability or a strength for certain countries?

Let's start by describing digital infrastructure. She is made of data centers, generally located in countries with an advantageous geographical and/or climatic position, such as the Netherlands. This country, ideally located in Europe, has a strong renewable electricity production and attracts investments from GAFA. Google is the example: 1 billion euros invested in the construction of a new site in the country. This type of investment economically benefits the countries concerned.

The global digital infrastructure also relies on its submarine cables. As a reminder, the internet is fundamentally dependent on this open network. Initially, this network was mainly administered by telecom companies which formed consortia. Today, it is mainly big tech who have become the owners of submarine cables.

To realize the vastness of the network, a simple link is enough: https://www.submarinecablemap.com/ . There is a real correlation between access to this network and economic and technological development.

These networks carry technologies such as cloud, which are mostly properties of North American big tech. Like many other tools, the software industry is not immune to geopolitics. We had an example of this recently with the Russian-Ukrainian conflict. Russia was disconnected from the SWIFT system, but more insidiously, the Russian population lost access to Google Pay and Apple Pay services. All these elements have become real tools of pressure on populations when it comes to attacking other countries. They are also tools of population control, as can be seen with a closed internet network and controlled in China.

The political projects to be considered in the years to come are:

This second conference, led by Romain Couturier, focuses on the challenges for the Agile of the future.

My life is a ticket! Praise of lazy communication and challenges for the Agility of the future

This conference stood out thanks to its format. Indeed, in addition to Romain Couturier's eloquence, he drew his presentations live on paper, making the pace perfect for acquiring new knowledge!

It therefore begins with a brief explanation of what the agility. In itself, nothing more than a simple Framework, a tool. Nothing new in the tropics! But how well do we master this Framework? And what are the bonnes pratiques ?

The presentation continues with the explanation of a concrete case and the answer to a question: how does a team organize itself with its production flow? We have a list of features divided into User-stories, what to do now? Romain Couturier answers these questions with 6 steps:

However, Romain raises a point which in my opinion is the keystone of the success of a controlled workflow: defining when a task is finished. Indeed, this is where there will be a lot of back and forth between the production team and the client/business. This is why it is important to define under what conditions a task is completed. And for that nothing could be simpler: you have to write the sacrosancts case of acceptances. THE happy paths are defined by the Product Owner (PO) and chess cases by Quality Assurance (QA) tester.

Romain continues with the analysis of a situation that we all know: the emergency.

It exposes urgency as the enemy of focus and therefore productivity. For what ? Because it causes a change of context which requires us to reposition ourselves in the technical and professional environment of the emergency, generally different from that in which we find ourselves. He therefore proposes to remove the notion of urgency from the normal production flow. (Of course this caused giggles in the audience and raised many questions at the end of the conference).

I will summarize the exchanges as follows: each emergency must be prioritized and planned in time. The only possible exception is if the application or service is knocked out because it causes immense losses. But overall, roll-back/backup tools must be put in place to avoid or at least control, as far as possible, this type of emergency.

Finally, in good practice, it also suggests avoiding saturated systems. That is to say, see what is the rate of production (in quantity of US for example) of the team and remove a unit (of US to take the example) during the sprint planning.

Finally, Romain gives one last piece of advice: clean up the tickets. He recommends deleting tickets that are too old, misunderstood, too complex. They were certainly created with a purpose, but if the project has been running for 2 years and the ticket is still active, it is that it is not really important, so make it disappear! This will make your more readable backlog, welcoming (for new tickets) and will reinforce the team's knowledge of what is to come and/or to be done.

Egoless programming “The 10 commandments of egoless programming”

Finally, the last conference David attended was presented by Olivier Thelu on the ten commandments of egoless programming ) "egoless programming")

The conference begins with Principle No. 1 of Agile manifesto :

“Individuals and their interactions more than processes and tools”. Indeed, we tend to forget that processes are only organizational tools, and that this organization is first and foremost made up of humans who must interact and not exchange through comments interposed on a Redmine ticket.

In order to deal with this subject it is important to define what the ego is. This usually results in a person by:

In the development world we often face it when we have to make technical decisions, when we make architectural choices, or when we define the quality standards of internal company code. This usually results in trolling (for boomers who don't know what it is, it's cynical mockery 😉. It may therefore appear a certain difficulty to show your code or even feel ashamed to expose yourself to the judgment of the other.

The simplest example is often that of the developer coming out of school, who has become accustomed to being constantly in competition during his practical work. This pedagogical model has its limits, of course, which is why it is important to teach them that there are no stupid questions, that mutual aid is absolutely essential and that it is even the best way to acquire skills and knowledge.

But to be certain of becoming a egoless programmer, it exists 10 commandments, written by Lamont Adams (originally taken from "The Psychology of Computer Programming" by Gerald Weinberg written in 1971)

1. Understand and accept that you will make mistakes
              
2. You are not your code
              
3. No matter your level, you will always find stronger than you
              
4. Do not rewrite code without discussing it
              
5. Treat people who know less than you with respect, consideration and patience
              
6. The only constant in the world is change
              
7. The only true authority comes from knowledge, not position
              
8. Fight for your ideas but accept “defeat” with benevolence
              
9. Don't be the person in the back office (the person who works alone in his corner)
              
10. Criticize code instead of people, be nice to them but not the code

The last point seems essential to me. It is important to be factual, to write in a positive way and to remember that it is a person who will read your comment. It is essential to ALWAYS suggest improvements if the solution does not suit you.