Hello Sallah, can you introduce yourself in a few lines? And what are your missions today?  

Hello, I am a Software Engineer passionate about technology and clean code. In addition to my years as a code enthusiast (high school, college, engineering school), I have 14 years of experience, mainly in France between Sophia-Antipolis and Paris. I also had the opportunity to work in California (Palo Alto) and in England (London). In the last few years, from Morocco (Casablanca), I work with companies in Africa and the Middle East on digital redesign programs. I help them to set up a technically mature delivery organization, make the right technical and technological choices to support their business strategies, and implement software solutions to give them a competitive advantage.

 

At what point in your career did you discover Extreme Programming (XP) and related practices? 

The first time, it must have been in engineering school. But I understood the interest and the added value in a professional environment. 

 

What did it change in your perception of the developer’s job?  

The sense of professionalism in software development and coding ! After a few years of experience, I think that understanding XP and knowing how to apply it during a project allows you to approach software implementation as a true professional. It is one of the methodological frameworks that really stands  out. With this box of methods, if understood, accepted, and adopted by the team, one realizes that it is possible to do things differently and thus produce a more easily maintainable and extensible code. 

XP is a  framework that provides a better development experience (DX), supports creating code that is predictable, with fewer instabilities and prevents spending sleepless nights trying to fin the “million-dollar bug”.. Imagine a readable code with which all team members feel comfortable, somewhat like a condominium where the occupants feel comfortable, that’s what it looks like. The flagship method of XP is TDD, or Test-Driven Development. Just like a craftsman, the developer has toolboxes that allow him to do well, to do better, and even, to excel.

 

The first time you discovered the concept of technical debt and experienced its substantial impact on a project, what was your feeling ? 

Astonishment, because I had personally contributed to it.

Then indifference, for overlooking the extent of my contribution, even minimizing its impact on the project. Finding as an excuse, that in the end, the software got delivered on time, and with all the requested features. And if there is one job where the adage “it’s only the result that counts” doesn’t work, it’s IT.

Then the fatigue, compensating for this by working countless hours, trying to remedy the apparent problems while reproducing the same mistakes. Because basically, the method did not change: “coding without testing”. And unfortunately, you can’t solve a problem with the logic that introduced it. Indeed, TDD, for example, was not on the agenda. 

Then anger, for realizing that as an Engineer, I spent several years working technically like an amateur.

Then curiosity, by discussing with the Craftsmanship communities and other practitioners who swear by TDD and other XP development best practices. 

Then pleasure, having tried it on pet projects. I felt like I was relearning how to code. The switch was not instantaneous because habits are hard to change. However, the interest grew because I could appreciate the stability and the readability of the code produced, which made me want to apply it in my company.

Then the pride, by starting to enjoy, by learning and by influencing other colleagues to follow the good practices, by seeing the technical and human impact which was at least beneficial for reducing the technical debit and keeping it at a low level..

 

Every company would like to produce sustainable, bug-free software with code and architecture that remains clean over time. Why is it so difficult to achieve this ?

I’ll try to answer this question based on what I’ve seen in the software industry over the last few years, working with multinational software vendors, startups, and non-technical players providing digital services.

One of the reasons for this, might be that it is not one of the primary desires for all companies. 

For software companies, this is undeniable, as it is the primary source of revenue for the company. For others whose core business is not IT, Software is a more or less an essential asset to increase their income.

For companies in the first category, it’s easier to do it very well because they mainly target code professionals and deploy an adequate HR retention system. On this basis, the Engineering culture is at its peak, with the latest technological means to remain competitive, with some gems of their own making, whether as proprietary or open-source solutions. In this type of environment, it is generally difficult for a developer to do anything but clean, quality code and viable architectures. In such companies, developers are usually considered as first-class citizens.

For the second category, it’s more complicated. Code is generally perceived as a mean rather than an asset. There is a generalist HR system with no real incentives to maintain an Engineering culture and a strong technical identity over time. In the long term, Career paths are also oriented more towards business tracks than technical tracks. And this is understandable because as long as these institutions recruit Engineers, they assume that they will act as code professionals and produce high-quality software by default. 

For these companies, it’s assumed that developers will ensure that robust architectures are implemented and maintained. This is the mistake; the engineering culture in the company should be nurtured and rewarded, rather than expected and reprimanded for failure. If engineering culture is not a priority, the recruit, in general, will grow up aligned with existing practices, replicating the bad habits of their peers, maintaining technical debt, and sometimes having little awareness for the negative impact they could contribute to. In this context, teams are generally interested in short-term results, look for shortcuts to boost delivery times, and unfortunately end up delivering features over quality. In the best of cases, a known and regretted technical debt, and in the worst known and assumed. 

In either context, producing clean code is taken for granted by companies. And it is how they maintain and enhance this asset that makes the difference.

 

One of the challenges of the last few years is to scale Agile in companies. We have the impression that today we are trying to do the same thing with Software Craftsmanship, and technical quality seems to have been somewhat forgotten in this affair. What is your view on this ?

Indeed, Agile has turned the software industry upside down, and for a long time, companies saw it as a solution to deliver faster while staying  closer to end-users.

But, when companies want to scale up, they realize the limits of the system I described earlier in the second business context. Some describe this as the “Agile Hangover”.

As you can see, it is not sustainable at scale to have technical debt, rough engineering culture, and knowledge that is diluted by turnover.

Software Craftsmanship is one, if not the only manifesto and community movement, that fills a gap in the triptych to date: 

• Do the right thing: Agile
• Do the thing fast: DevOps
• Do the thing right: Craftsmanship

 

What were the challenges for you when you helped teams gain technical excellence ? 

The top 3 :

• Habits: When teams have been used to working with shortcuts for several projects, it becomes very complicated to implement good practices. Change management requires empathy, repetition, and humility.  
• Sponsors: it is crucial to ensure that you have the support of the management team and managers. As some of them are not technical, you have to leave your comfort zone to rally goodwill and explain the usefulness of the change and its benefits on the business and operational dimensions.  
• Time: especially Time to Market. This is an obsession for any business. However, the only way to go fast is to go right (Robert C. Martin). And that’s easier said than done. Juggling speed and technical rigor are significant challenges in everyday life, both with developers and business players.

 

How do you think “non-technical” people look at the Craft values ?  

At first sight, gibberish and skepticism 🙂 More seriously, non-technical people understand a language and accept non-technical concepts easier. And, this is quite normal. If you speak with a CEO of a company with an MBA and financial background and tell him, we’re going to make quality code like a craftsman would, he’ll be amused at best and annoyed at worst. But go to him and tell him that the company is losing a few million dollars a year because of a lack of technical maturity and that the market trend is Craftsmanship. He will look at you and listen to you as long as you stay away from tech jargon: TDD, BDD, Refactoring… the same thing applies to HR managers, non-technical managers, and other functional employees. After a few iterations and by dint of talking about it, one can be pleasantly surprised, because one of the reactions is that these values could be applied to any job as soon as one becomes concerned about the know-how and the quality of what one produces.

 

Why may a team not have an appetite for these subjects and this desire to improve their development practices ? 

In my opinion, to create an appetite, the 3 main actors must have an interest:

• The individuals: first of all, the developers, by realizing that it offers them a better daily experience and more exciting opportunities in the medium-long term.
• Companies: by offering a framework for HR and operational enhancement targeting the maintenance of good engineering practices.
• Schools: by revisiting the school curriculum and embedding XP / craft values and practices as a central pedagogical ingredient. 

To date, I have noticed that the software industry is lacking in each of these areas.

 

How can we gradually build up an appreciation of XP within a team? And what are the necessary investments (time, means, etc.) ? 

There is no magic recipe. 

But what comes most naturally to me starts with getting a buy-in from management about the  problem and a business interest to remedy it. 

A second step is to deploy a company policy switching the software from mean to asset. This policy will have the effect of tuning the business functions to support the development of the software products/services and not the other way around. And as a result, this new policy will affect:

• HR: recruitment, development, and retention of talent 
• Infrastructures: modernization of software development factories and runtime environment
• Operations: build around the software to be produced

Concerning the financial means and the time needed to change, I would say that this is probably not the debate. It is an “ongoing” effort to be carried out as long as the business sees a return on investment and competitive advantage.

 

In an IT organization of several dozen or even hundreds of people, how do you create and maintain a culture close to Craft values ? 

There are three main ingredients:

• A strong CTO, VP-Engineering profile: you need a leader who understands the craft and sees its added value because it is this actor who will convince and influence the organization daily to change and maintain the focus.
• A Guild: a group of passionate, non-hierarchical, cross-functional people who share a common interest in good practices and who meet from time to time to practice together and communicate about their craft.
• An investment: you need a minimum of means, sharing spaces, quality PCs connectable to the internet :), HR incentives (conference tickets, ..), spare-time management.

 

There is also a growing awareness of the importance of “soft skills” for developers. What do you think is the right “Mindset” today when developing in a team ? 

It is indeed essential. It is no longer enough to know how to code, you must also learn how to develop a good relationship, and the software craftsmanship manifesto and XP illustrate it well.

Some key skills:

• Egoless programming: putting ego aside to carry the nature of the debates around the software to be delivered rather than on judgments.
• Courage: reaching out to others and taking a stand on good development practices.
• Empathy: put yourself in the other person’s shoes, and I would even say in the customer’s shoes. Without this, we cannot accompany the change or approach a solution that will be truly useful and value-added for the end-user.

I talk about this in detail in my book in the section on soft skills. Having the right attitude is the ingredient that makes the difference in personal development, which consequently benefits the whole team.

 

In terms of attitude and mindset, what are the recurring pitfalls and problems you observe today ? 

• Haste: Companies are struggling because they want to accelerate but don’t know where to start and how much effort to engage. Employees who want to grow fast by looking for shortcuts at the expense of mastering their know-how. I would say that this is one of the plagues of our economically globalized generation.
• The savior coder syndrome: companies will put forward a specific intervention where an employee distinguishes himself by saving the situation, which in itself is a good thing. But sometimes, it’s the same coder who is at the origin of the technical debt maintained with his team. This gives the sweet illusion that there is no need for change and that we can always get out of it with one-time interventions. This syndrome does not allow for scaling up. Ideally, any team member could save the situation if good practices are applied and knowledge is shared.
• Fear: changing the method, the way we work, is like committing to the unknown. It is a risk that few people are willing to take, especially in social or corporate cultures, where mistakes are perceived more as a defect than learning opportunities. 

 

You talk about knowledge sharing and applying best practices; this is a subject that interests us a lot at Promyze. How can we get the knowledgeable people to share and those who know less to receive that knowledge ? 

Thank you for the question. For a good reason, it’s a central element of Software Craftsmanship. I quote an excerpt from the manifesto: “raising the standard of professional software development by doing and helping others to acquire the know-how”. 

With this element introduced, I would say that it is essential to have a federating movement, which allows crossing the interests of some and others around common challenges and aspirations. Software Craftsmanship embodies this perfectly.

If I had a suggestion, it would be to contribute to the development and strengthening of these communities by providing them with the means to connect, be even more visible among themselves, and share their knowledge and practice on a common platform. 

I am a big believer in virtuous circles. From contribution to contribution, it would provide a framework that would make experienced people want to share more and others, near or far, the willingness to join, learn, and then contribute back in return.

 

What do you think needs to change in companies if they want to achieve the initial goal we were talking about, i.e., to produce sustainable code ?  

Probably a value-oriented approach, rather than a result-oriented approach. And shift towards the value of the ‘HOW’ (the methods, the practices, the process to deliver the product and service to the customer), in addition to the ‘WHAT’ (the product, the service that the customer receives). To date, the WHAT is usually the KING. For example, highly adopted Agile is more focused on the WHAT, while weakly integrated Craftsmanship is more focused on the HOW.

 

The discovery of Extreme Programming practices is a subject that seems to be gradually finding its place in educational curricula. What is your point of view on this ?

It’s very positive. To my great joy, more and more educational initiatives inculcate the methods and values of XP. Whether it’s certification courses for professional conversion, introductions to good code practices in companies, or TDD courses in universities, the pace seems to be accelerating. Given the increasing consumption of digital solutions, users are becoming more demanding in terms of software service quality. For two products with similar functionality, they will prefer the one with the best underlying quality. It is not enough to provide beautiful screens, the response time performance must be there, the data must be secure, and the service interruptions must be almost non-existent. The next few years will see a strengthening of practices in schools and businesses to meet this growing market requirement.

 

You also had the opportunity to discover Promyze recently. What do you think are the strengths of the solution ?

I really like the DNA. Many companies focus on service delivery and advocate Craftsmanship, but few offer software solutions to operationalize it. Promyze is a perfect example. The technological positioning is interesting. I really like that the solution integrates with tools on the market that both companies and development communities appreciate. I am thinking in particular of your plugin on Intellij IDEA or your integration with SonarQube. One of the significant strengths that I also see is the interface that promotes the creation of best practices collaboratively, allowing teams to take ownership and customize their approach to technical debt.

A big congratulations!

 

Promyze offers team workshop formats to bring out good practices. Which technical rituals can be implemented in this continuous improvement process ?

I think it’s excellent because it insists on team exchange and creates a feeling of “collaborative ownership”, as recommended by XP. In the continuity, I would like to see a set of Katas illustrating how to solve a technical debt with specific solutions, step by step, highlighting techniques such as TDD in synergy with Refactoring.

 

You published a book on Software Craftsmanship last year. Can you tell us more about the genesis of this project ?

It all started with a 3-week training program, in Bootcamp format, that I had set up to onboard 14 young developers within a banking group. The objective was to increase their skills to be operational on the bank’s digital projects. It was an incredible adventure, both humanly and technically. 

A Bootcamp that allowed us to work on four dimensions:

• Soft skills: The right attitude, the soft skills to adopt and cultivate.
• Know-how: the methods to practice to produce quality code and the pitfalls to avoid regarding technical debt.
• Structuring skills: frameworks to know to model problems and reflexes to have to obtain an evolutive architecture.
• Thinking: developing a technology watch method and learning how to identify and follow the most influential people.

Through this cycle, I realized that this program did not only contribute to introducing these developers to good practices. It was also very beneficial in terms of human interaction, creating a mentoring framework with other company experts who shared their experience feedback, a summary  of attention points when coding in enterprise, and the secrets of specific methods that require reading books of more than 500 pages. I am thinking in particular of Eric Evans’ DDD. The most striking thing is that most of the concepts discussed are described in detail mainly in books written in English, making them  sometimes challenging for a French-speaking population to access.

This is how I started writing my book, with the idea of sharing the different lessons learned during my various years spent in different business contexts. I wanted to make accessible the other key notions of the software industry that I went through during the Bootcamp. And finally, to give a taste and make accessible the Craftsmanship to all developers wishing to progress in the company as code professionals. And finally, also to practitioners willing to know better the Software Engineering Excellence universe.

Software craftsmanship: the art of code and technical agility in business

Published in 13/11/2019 by ENI

Link