Introduction
Legacy software is everywhere. Many of us are struggling everyday with code that was written in a hurry to meet a deadline by someone who is long gone and nobody really understands their code.
Business guys are angry because every tiny feature that they ask takes weeks to implement and deliver, and production incidents arise too often. Unfortunately, for many developers this is the true life of a software maintainer.
More than 10 years ago, the Software Craftsmanship movement was born to tackle these issues and raise the bar of quality software and professionalism. For many, this was the light at the end of the tunnel, a ray of hope that could transform the software industry.
For some companies, it worked, and they were able to reach a higher level of quality and development culture. But for too many others, this movement just didn't work as expected. Sure, developers liked the concepts and methodologies promoted by the Craftsmanship movement, but they just couldn't put them in practice because of other intervenants : either their product owners or their managers were still pushing them to deliver as fast as possible, they didn't understand the benefits of craft practices, they were reluctant to let developers learn new practices like Test Driven Development, were too afraid of the possible regressions that can be introduced by refactoring, thought of pair programming as a waste of time (2 developers working on the same subject whereas each one can handle one story ? non sense !)...
This was the context in my current team. We had been paying Craft and Agile coaches for years, but the Craft culture was just not working as promised. My manager decided to try another approach : he asked me to prepare a training session targeting non technical people, to learn them the basics of modern software development and make them realize the benefits of Craftsmanship and, more generally, software quality.
One training to rule them all, and in Craftsmanship bind them
When I started building this training, it quickly became clear that the main difficulty will be to allow people that never wrote a line of code to feel satisfied by the results of their work, while still interesting former developers. Just doing some small "Hello World" examples was not an option. So, I've thought about one crazy idea : what if students attending the course could develop a real application fulfilling one of our business needs, reaching the quality standards of our company, that we could deliver on the last session of the training ?
This seemed challenging at the time. I had many subjects that I wanted to share with students, but we wanted this course to be accessible to as many people as possible. So, first decision was the format of the training : it would be made of 12 sessions of 2 hours, with about half of the time dedicated to a theoretical lesson and the rest would be some practical exercises. We'd need to start small, and then add complexity and features little by little as students would feel more confident.
After a bunch of brainstorming sessions with my manager, we decided to build an API to handle Swift messages, a kind of flow that our applications need to handle very often. We've prepare a program of 12 thematic sessions:
- Introduction and installation of the tools
- Object Oriented Programming Basics
- Automated tests (2 sessions)
- Clean Code principles
- Continuous Delivery
- Creating an API
- Working with databases
- Security
- Preparing our application for production
- Live production delivery
- Retrospective
In order to know where we were going, I had to develop a prototype of the application we were going to develop, to make sure it was feasible for people discovering development. To make things easier and to follow the guidelines given to our developers wanting to develop APIs, I decided to use Spring Boot's ecosystem: we will build our API using Spring Web MVC, rely on Spring Security to handle our authentication, use Spring Cloud to register through our service registry, communicate with the database with Spring Data... Thanks to Spring's magic, it would allow the wow effect of having a whole application with just very few code to write, and moreover it would allow us to build it brick after brick, which was perfect for my planning !
But there was still one issue : Swift messages are quite complex, and there is a lot of messages type. At first, I thought that each student could model one type of message, but I quickly understood it was not going to be possible for newcomers in just a few hours. So, I've started looking for an opensource library that we could use. I found one (Prowide), and it greatly simplified the work for students while promoting reusability instead of reinventing the wheel.
Registration time
With the skeleton of my course ready, it was time to find students. We talked about our idea to our managers, to business analysts, and we even asked Ops team what they thought about it. It appeared that many people were curious about the initiative and wanted to be part of it. We originally planned to have a 8 students class, we finished with 13 students divided into 2 promotions !
The profiles were very diversified: we had business analysts that never learned how to code, others that did a bit of development at school, we had managers that didn't code since more than 15 years, Ops that knows a lot about scripts coding but never practiced OOP...
While this successfull enrollment was a joy, it lead to the greatest difficulty I was going to face : how to satisfy such various people ? How to teach to the full beginners while not boring the ones with some prior experience ?
Adapting to everyone
The first decision to mitigate this issue was simple : since we needed 2 promotions, we've defined the groups depending (as much as possible) on their existing knowledge : the first group would be composed of people already having a developer experience, whereas the second one would be for beginners. Since both groups will have their weekly sessions in 2 different days, it also allowed me to adapt my lessons and practical exercises: if "experienced" students were struggling to understand one aspect or implement a feature, I would change the way I was using to present the subject and give more detailed instructions for exercices, and even live code with students for the most difficult parts. And of course, the most important point was to make sure that everyone understood as much as possible what we just learned before leaving the session. I allowed them to interrupt me everytime they had a question, I didn't want them to let go about something that would not be clear.
For the theory, lessons needed to be as clear as possible: I needed to focus on the key messages that I wanted them to remember. Of course, some subjects were only briefly mentioned, but every time someone wanted more details, I tried to vulgarize as much as possible (sometimes giving them a bit more details to tease them ;-) ). The overall idea was to keep the lessons short and to infuse the key takeaways about coding and quality that we want to spread in our teams.
Feedbacks of the experience
For the beginners, the first sessions were painful : since we didn't have a lot of time to cover the basics of programming, especially the syntax of the language (Java), they struggled to write simple lines of code. After a few weeks, they started to understand better the concepts we were manipulating and were a bit more confident.
In the end, they all realized that the developer's job was very different from what they imagined or what they knew in the beginning of their career : they were impressed by the number of topics and technologies a developer had to understand and master in the context of a modern application. But they were also relieved by the quality of the tools (IDE for instance) and the incredible choice of libraries that are available and ready to use. Most importantly, they understood the benefits of craft practices : when a manager told me that the test harness showed him that his refactoring was causing a regression, I was happy. When they told me that the code they just refactored was easier to understand and to evolve, I was happy. When they told me that they understand better what being a developer means, how they work, what are their constraints and why they need to focus on quality, I was super happy.
It is still a bit soon to know if this experience will change how our teams work and how we tackle the issue of our technical debt. But from the conversations I'm hearing in the openspace, some progress are already there :-)
But this initiative is not over : people from other entities of the company have heard about it and want to join the next promotion. We even proposed our top management to join us. We want our offshore teams to reproduce the course within their teams as well.
The next step is to make sure that we can leverage on this "craft trend" : we need to keep insisting on the benefits of craftsmanship, not only with developers, but with anyone involved in the development of our systems, hoping that this time the quality culture that we want will not fade after the departure of motivated developers.
Top comments (0)