Experiences - Craftech

Here is a detailed reading of my past experiences over the last 10 years, which I feel are more significant and representative than anything I have done before.

2020-2024 : product mindset and concrete use of Domain-Driven Design

Context : by switching to a client in the Hospitality domain, in Thomas Pierrain’s team, I was able to improve and consolidate my knowledge about testing and how to better integrate the business into the code. I was then able to take things a step further by making a lasting impact on our team’s processes, as well as those of the department.

Concretely : despite a difficult health situation for the hotel sector and thanks to a strong and understanding client, I was able to work efficiently with business experts in order to maximize added value delivery for our products (including but not limited to the backend of the public websites) :

on 2 different projects in 2023, I set up a workflow based on partnership, discussion, education, trust and transparency. Relations with the business teams and project management were greatly improved and the software was delivered seamlessly into production, with little to no bug. Since I am fully aware of the damage that can be caused by accidental complexity, I managed to keep the code and dependencies to the minimum. My communication and vulgarization skills as well as the robustness and adaptability of our code were highly praised by the business teams.
Constant challenges to improve our processes and the software quality. Notably I was at the origin and in charge of the “How to work together” initiative that impacted several teams in our department. This initiative followed the feedback the teams made in early December 2022.
At team level, I was a proponent of having a product mindset using flow (Kanban-like) methods to reduce the TTM (Time to Market) and improve the business value of our deliveries. Some Scrum ceremonies were kept (retro, stand up meeting) but others like sprint planning or grooming were replaced with on-the-fly meetings with domain experts where they showed us the upcoming user stories along with some examples and the overall context. We were then able to discuss the items to get a better grasp at what was expected and reduce or even remove misunderstandings. I encouraged regular discussions with business experts in order to remove ambiguities and avoid bugs or fix them before they reached the production environment. The key point here was to ask the developers spend more time in the problem space rather than in the solution space. Using this approach, I contributed to improving the relationship between our team and those at business level thanks to my transparency, communication and the quality of the sofwtare I delivered.
used hexagonal architecture to have the technical code depend on the business code and not the opposite.
set up acceptance tests rather than unit tests in order to test the entire application in the case of a specific business case. Developed technical builders inside an architecure with complex and multiples dependencies ; shifted to a fluent API and a more functional pradigm to remove useless declarative code. Used fuzzing to generate random data for tests.
large performance enhancement project for the “prices and availability” service on our websites’ backend. After several weeks’ work, the result was a 30% reduction in user waiting time and a 5-fold reduction in the number of calls between dependencies.
organized Event Storming sessions with domain experts and various technical actors (devs, tech lead, staff engineer…) in order to align models and share the same vocabulary to avoid recurring confusion and implicits.
set up several eXtreme Programming practices : pair/mob programming, collective ownership (to break silos and avoid the “bus factor”), coding conventions…

Pros : I am glad I was able to find new ways to write tests so that they can be understood by non-technical persons. I was able to confirm that a product mindset is much better than a project mindset when building a quality product and generate business value.

What I would adjust in hindsight : during a forced technical migration, the organization switched to “project-driven” with plannings and an important pressure coming from management. It had a negative impact on the product, on the team’s mood and on the productivity overall. I should have communicated sooner to reassure the management on the team’s progress.

2017-2019: development of DevOps skills and source of proposals

Context: I was seeking to consolidate the gains of the previous 2 years in order to help my clients optimize the value delivered by IT projects. I was able to take part in a major project to overhaul the information system at a major energy account.

Concretely : for more than 2 years, I took several actions to improve the work methods and to take ownership of our development tools:

de facto tech lead on a critical project: test driven, mono repo and trunk based approach with semi-continuous delivery (up to pre-production environments where we didn’t have control). The complete project scope was developed in 2 months with 4 people (FTE of about 2.0), with very few bugs thanks to the good test coverage and the seniority and rigour of the team.
setup a dedicated build server for the team. Another server existed previously but was shared for the whole department and had limitations that slowed us down (not enough processors, limited disk space). I believed it was important for the team to take back control of this crucial issue in order to free themselves from the constraints induced by the old way of working.
automated regular tasks that were time-consuming and prone to error due to human intervention. Most notably a task that used to take several hours became a script launch of less than a minute and a pull request.
organized katas about TDD at lunchtime, once a week for 6 months.
referrer on Git and the Gitflow-like branching model.
migration from Team Foundation Server to Azure DevOps. Referrer Azure DevOps for the team.
permanent questioning of the methodology, with the constant aim of improving the quality of the team’s operation and deliverables.

Pros : nice rise in “DevOps” skills in a spirit of better mastering our tools until the delivery in production: Azure DevOps, build server, delivery, archiving and versioning of binaries.

What I would adjust in hindsight : knowing how to better recognize lost battles in advance.

2015-2016: increased skills in software crafting and source of proposals for the customer

Context : in a large investment bank, thanks to an awareness at the top management level and a very good team, I was able to discover and develop craft skills and then make ambitious proposals on impacting subjects.

Concretely : an excellent synergy in the team where I arrived allowed me to increase my skills on :

TDD through the regular practice of katas,
BDD and how to get the most out of a discussion with business experts,
DDD to reduce the strong couplings that were crippling our applications,
agility to avoid getting stuck in a methodology by applying it without questioning its validity (especially on the subject of planning pokers and other costly estimation techniques),
the values of software crafting in general, including continuous improvement and partnership with users, in line with what I saw in my previous job.

Following this, I was able to carry out 2 concrete actions:

in terms of agility and organization of the team in general, I proposed to move gradually towards a model more based on flow (ex: Kanban) rather than staying with Scrum which some ceremonies did not seem adequate to me. In the end, we lightened and then removed the sprint planning points that were both annoying for the business people and not really useful for the IT people.
on a technical level, we started with 2 colleagues on our free time a prototype to better separate the responsibilities of several components. The point was to respond adequately to heavy legacy code. This initiative met great success with the management but was not continued afterwards due to lack of budget.

Pros : it was for me a pivotal period where I was able to realize the extent of the current state of best practices (craft, agility…). These are things that have profoundly changed my way of working and my relationship with my colleagues, whether they are users, developers or managers.

What I would adjust in hindsight: I would probably moderate my desires and expectations. I really did a lot of work at that time, especially if you add the extras for my employer (see next section). I ended up getting really tired and the change of project manager in 2016 dealt a heavy blow to my motivation.

2015-2016: increased skills in software crafting, change agent at my company

Context: while discovering the values of agility and craft, I wondered why nobody had tried to promote all this internally at my consulting company while we were more than 120 employees. So I set up various actions to make most of the trades aware of these subjects which seemed to me to be the future or even the present for IT professionals.

Concretely: in about 18 months and with the help of my manager, here are the actions that have been undertaken:

presentations on TDD, software crafting, Clean Code. They took place at lunchtime in my company’s premises and about 15 people attended on average.
invited several recognized guest speakers on various topics related to software crafting. Live coding, legacy code refactoring, etc…
presentation to the internal staff (sales, general management, HR) of our vision on the evolution of software development. Craft, coach, DevOps… so many keywords that are commonplace today but were not in 2015.
presentation of software crafting and workshop at other customers’. We took various elements of our internal presentations to apply them in a workshop with a kata.
creation of materials to set up a craft training course for newcomers. 2 supports were created but the training was not given in the end.
organization of code retreats during the Global Day of Coderetreat in 2015 and 2016. On each of these dates, about ten people came to participate.
agreement with HR to set up the “one conference per year” system, in which each employee has the opportunity to attend the conference of his or her choice for training purposes.
formalization of the “companionship” system, a structure to support each employee in their progress and reward them for their contributions.

Pros: I learned a lot and really felt that I was helping other people grow in their professional life.

What I would adjust in hindsight: Like in the previous section, I would get less excited and probably reduce my workload.

2012-2014: introduction to agility and value delivery

Context: I was working on several projects for an asset management client and was in charge of the technical aspects of a tracking and reporting software for the Middle Office.

Concretely: I was able to learn the virtues of working directly with users or one of their representatives, without an intermediary and with a respectful approach on each side. This allowed us to manage changes quickly, with close deliveries to test environments to deliver value. Here we find several pillars of agility and software crafting: individuals and interactions, collaboration with the customer, response to change, productive partnerships, adding value.

Pros: I was able to unknowingly grasp a concrete approach to some of the points promoted by agile methods. I left with the feeling that I was really able to help users in their daily work and develop a real relationship between the business and IT.

What I would adjust in hindsight: I would probably make formal points a little more often; we had a weekly meeting of one hour whereas 10- to 15-minute sessions 3 times a week would have been more appropriate in my opinion. From a technical point of view, I was not yet familiar with practices such as TDD, BDD and even less so DDD, which would have allowed me to go further both in the reliability of the application and its architecture.

Before 2012: awareness

Contexts: from start-ups to large groups, in-house or in service, I have been able to see very diverse environments and form my own opinion on the quality of the practices used.

Concretely :

an experience of more than 6 years with a major French software publisher allowed me to see both the importance of automated tests and a clear delivery process, despite the use at the time of a waterfall approach. I also saw that reinventing the wheel was rarely very useful or profitable…
then, my first contact with the world of finance made me realise that not all IT teams paid the same attention to quality! Fortunately, an understanding management team was able to give me the keys to progress on several application stabilization issues and to improve relations with the Ops teams. I was also able to discover the virtues of blue/green deployment, which enabled us to deliver during the day without interruption of service in a demanding international environment.
The next experience in a legacy environment taught me how difficult it can be to emphasize quality in an organization where emergency has been the norm for decades. At the end of the assignment, I was able to issue a list of recommendations that supported continuous integration, the philosophy now known as [DevOps] (https://fr.wikipedia.org/wiki/Devops), the use of standards (no need to develop everything in-house), investing in automated testing, stronger involvement of the business in the pre-release process (UAT, specifications…), etc….

Pros: I realize today that I matured well at the time and was able to learn as I went along in each of my positions to start being a source of proposals for my clients.

What I would adjust in hindsight: a lot of things :) Probably the arrogance of my beginnings, so typical of many juniors in our business. And also having ignored for so long to investigate the TDD track despite several signals throughout the years; I thought that seniority required more technical expertise and I was not interested in methodology or work practices. I could not have been more wrong!