“Whatever we conceive well we express clearly”
“…and words flow with ease.”
- Nicolas Boileau-Despréaux (1636 - 1711)
As developers, we often want to implement a solution quickly so badly that little attention is paid to the original problem and its context. And that is where bugs come from : we think we have understood the problem, assumptions are made, only a couple of scenarios are considered… and the target is missed.
This is a topic that is particularly meaningful to me. It feels important not to fall into the stereotype of the developer who gives more emphasis to the technical side of things than to the problem reported by the users. It’s simply a question of professionalism; what would we think of a household appliance repairer who would change the entire engine block of a fridge without taking care of the leakage problem we pointed out to him? Or who would advise us to change the whole fridge?
A healthy relationship with business users
The foundation for providing quality software is to have a friendly relationship with the users. In my experience if there is mistrust or even distrust between IT and users, then the main points will not be addressed. IT will be seen as a cost center and little value will be delivered to the business.It is therefore essential to take the time to listen to the demands; I am not saying that you have to accept everything, it is even vital to know how to challenge users, but you have to do it smartly and in an appropriate way.
" Not only customer collaboration, but also productive partnerships."
Consistent development practices
I use practices such as TDD and continuous integration daily in order to control the quality of the code I deliver. I am also very interested in the DevOps philosophy, not only to understand the challenges of managing a production environment but also to see how the software I deliver is deployed and maintained. To do this, I believe that any delivery in production must be a non-event. Notably by securing the complete upstream chain (automated tests, shared knowledge of the code and needs…) or by allowing quick and easy delivery (trunk-based development, continuous delivery or even continuous deployment).
Continuous improvement as a way to progress
I am aware that certain practices can only be carried out under good conditions. For example, continuous deployment is not conceivable if everyone on the team is not convinced of the usefulness of automated testing. The mob programming, which I recently discovered, allows both to create quality code but also to present new ways of doing things to everyone with concrete examples.
I’m also very fond of regular katas sessions on working time, ideally one 2-hour session per week, to allow everyone to discover and test things on simple problems outside the production code context, therefore in a more relaxed way.
