Here is the question I keep hearing almost every time I speak at a conference about object-oriented programming and my non-traditional understanding of it: “How do I convince the whole team to start doing everything so differently?” (asked here just recently). Indeed, it’s easy to change your coding habits and your software design if you are alone. What do you do if you are a member of a larger team where everybody is very happy with the Spring Framework and procedural programming? How do you change their coding habits? An even better question is: How do I not get fired while doing it?
TL;DR You can’t win alone, you need a gang; assemble it.
I remember a few years ago I joined a Java team as an architect and my boss told me that the team had very talented programmers, but they needed some help. He also told me that the architecture was great, but it needed to be improved to become even better. And he also told me that I was there to make changes, which they were looking forward to.
In just a few weeks I realized that the reality was very different. Most of those 30 programmers were actually junior and could barely tell the difference between an object method and a static one. I also found out that there was no architecture at all, just a collection of .java files created by different people at different times. And, of course, it became obvious that no matter how hard I tried, my ideas wouldn’t be accepted, simply because they sounded too scary to those “talented” people.
Seriously, if I had been one of those programmers, sitting there for a few years, writing some Java code and collecting paychecks twice a month, would I be glad to meet some guy telling me that I had been very wrong for the last few years and now it’s time to re-write everything? No matter how much sense this guy would be making, I would simply sabotage him to protect myself. No matter how much we declare the value of individualism and independent thinking, most people are very social and dependent on the community around them. In other words, they do what everybody else does. It’s safer.
Those 30 people were not any better. They were going with the flow, using Spring, and MyBatis, and Singletons, and getters, and setters, and everything else we, real OOP programmers, hate so much. But I had to do something about it, that is what I was paid for. However, just telling them that starting today we should get rid of Spring because it’s anti-OOP would mean only one thing for me: a termination of my contract, sooner or later.
Such a revolution would be a serious threat, both for programmers and for the product. First, it would put most programmers back in junior positions, forcing them to learn new paradigms from scratch, while they want to keep enjoying their “senior developer” job titles and salaries. Second, radical architectural changes always jeopardize the stability of the existing software.
This is what I did:
First, I picked the youngest and the most talented ones (at the same time). I talked to all of them and found out who had the highest potential. Pay attention, I picked not the best, but the ones I believed were most interested in learning and growing professionally. No surprise, they were the youngest (career-wise, not by age). It was obvious that they didn’t have enough professional mentoring and no growth strategy. It was Spring, what growth can we talk about, right?
Second, I unofficially became their mentor. This is what junior and ambitious engineers need most: a teacher. Someone, who can show them the learning path and the direction to new knowledge. My mentorship was simply about reviewing the code they wrote and telling them what was wrong, supporting my criticism with my own blog posts and many other articles/books I could find about “good” software design.
Third, I organized regular weekly lectures for the entire team. I was spending an hour every Monday speaking in front of them and explaining why NULL is bad, unit tests are good, and so on. Everybody was free to attend. No surprise, my “students” were always attending.
Fourth, I was refactoring the code base at some critical places and asking my “students” to review my pull requests. These small challenging tasks gave us good material to debate and united our sub-team even better. My ultimate goal was to assemble a gang who agreed with me. Reviewing each others code was a perfect method for this.
In just a few months it became obvious for everybody that the entire team was not that solid anymore. We had the mainstream majority and the true-OOP minority gathered around me. The status quo started to shake. The minority were not happy about the architecture and were not afraid anymore to say so. The architecture was still bad, but it was not “our” architecture anymore. It was something we inherited from the past and we were committed to changing it … eventually.
My first and primary objective was not to fix the architecture, but to build a coalition of supporters, and it was achieved. I didn’t manage to get the majority though. There were only 7 people in my gang. But this size was enough to change the direction of the entire team of 30 programmers. Others passively joined us later.
I left that project in less than a year (I wasn’t fired). However, when I was leaving, it was heading in the right direction: test coverage was growing, objects were becoming immutable, new DTOs were not being created, and so on. Spring Framework was still there, though.
You can do exactly the same in your team, even if your position is still a “junior” developer. Don’t wait until your boss changes your title, start mentoring people around you and building a team of supporters. When it gets big enough, the changes will start happening even without your will.
What is the best argument to convince a team?
— Yegor Bugayenko (@yegor256) December 1, 2019
