A few months ago, I wrote a RebelLabs blog called The 5 people in your organization that grow legacy code. In that article, I described five different profiles of contributors to your legacy code and after much discussion around the topic, I realized that the original post only identified the people and didn’t provide proper techniques to deal with them. So in this post, I offer some suggestions for dealing with these people. Especially since I am guilty of falling into at least one of these categories myself at some point, and probably so do you!
Let me start by saying this: I’m not a psychologist. I’m a passionate developer, like a lot of you, but I believe that our psychology is tied into everything we do. Bear with me for a while, this may not make sense now for the post purpose, but I’ll promise that it will by the end of it.
I’m pretty sure that you have heard this golden rule before: “Treat others the way you want to be treated”. I’m sorry, but I’m going to be very controversial here. This is WRONG! There! I said it. Let me explain…
I used to think the other way around, but I came to realize that all of us are different and all of us have different needs. Don’t get the wrong idea, you should always be polite and treat others with respect, but let me give you an example. I like people to be very direct to me and tell me exactly what they are thinking. That’s something I did as well, but I came to realize that not everyone feel comfortable or like to be addressed that way.
Ok! But what does this have to do with legacy code? Well, nothing… except for the fact that individuals like me and you produce all sorts of code. There are a plethora of tools that can help you fix the problem later on (when it’s much more expensive and annoying to remedy), but I wanted to help you eliminate or at least minimize the need to fix things after they occur, and focus on prevention at its source: the people.
Let’s look again into the profiles we identified in the original post and try to assign a few of their most usual behaviors.
The Overly Energetic Engineer
How they act: These kind of people are usually perfectionists with a high standard for quality. They like to ask a lot of questions and focus on key details. They can be very critical, but their criticism is ideally positioned around facts and not opinions. For that reason, they study a lot of specifications and other relevant information.
My experience here: If you have read my previous post, I described how I wrote something like the current JPA Criteria API. When I think about it, I realize that I did it because the work I was doing was boring (for me). I was just required to do some simple data access and a few business queries.
How to treat them: You should delegate important tasks to Energetic Engineers so they can have an opportunity to show their skills and get recognized for it. They get bored with routine work and need the freedom to explore and test different results. If you don’t want to end with a new API, investigation work is perfect for Energetic Engineers.
The Technology Enthusiast
How they act: The Technology Enthusiasts, as my label for them indicates, are very enthusiastic about their work. They are also friendly, open and like to speak a lot. Optimists by nature, they try to persuade others into accepting their own ideas. They usually wish to be recognized in public by their capabilities.
How to treat them: You should clarify with your Technology Enthusiast how things should be done. Facts should be researched to solve the actual issues at hand, no rearchitect everything to use the newest tech out there (this approach, ironically, can easily add to your legacy code issues). They need to feel included in the decision or they might try to secretly squeeze in the latest JDK. (Which is pretty good by the way, everyone should download it!)
The Elusive Firefighter
How they act: Firefighters have your back. They enjoy helping others and like to work in teams. As they are usually patient, it might seem like they aren’t doing terribly much at any given time, but they know how to calm people down in stressful situations. They ask questions and investigate facts. They try to not take risks and don’t like to make unnecessary changes to their work.
My experience here: I’m pretty sure that many of us have already experienced that blocker bug that needs an immediate change to the code with a release as soon as possible. I usually call that the “Release Now syndrome”. Since Firefighters are pressured to fix the problem, they try to make the smallest changes possible to correct the issue. This seems to be the correct approach, because large changes could take longer to test and can impact other stuff. Unfortunately, putting a bandage on a case of leprosy doesn’t do much for the long term, and your code needs far greater care.
How to treat them: You shouldn’t pressure the Firefighter. They need to feel confident in what they is doing. Provide them with accurate information that give them guarantees. They might need a step-by-step plan and detailed instructions/expectations in order to proceed.
How they act: Smartasses want to get instant results. They are very demanding and impatient. They like to accept challenges and take quick actions. They usually try to impose their rules and lead other people. Often the nemesis of the Energetic Engineer, the Smartass usually makes facts of their own opinions.
My experience here: I was once in a project with a Smartass. No one really knew much about the technology, the client or the business requirements, so he ended up calling the shots. Decisions were taken without calculating risks and we went down a path where we had to rewrite a lot of code that we already had in place. I’m not blaming the Smartass, the entire team was responsible. Why? Because the Smartass needs someone to weigh in the pros and cons, someone that thinks before acting and investigate the facts.
How to treat them: If you are in this kind of situation, instead of approaching the Smartass with nothing on your hands, you should have with you all the relevant information for the problem and a few alternatives. Provide them with facts and direct answers. Since they don’t want to waste time and want to move forward, providing them with your already thought-out solutions may save your team some sleepless nights!
Wait a second! What about the Intern? This archetype is missing from the original post. True. When I was writing about the profiles, I felt that the Intern is just a temporary stage. After all, a passionate developer like you wouldn’t remain an intern very long, right?
People are not exclusive to one profile. They can adopt any behavior, or even a combination, but I do believe that they have one profile that is predominant.
If you got this far on the reading, maybe you were not expecting this kind of article. How can this help you improve your application code? In a simple sentence: by driving someone’s behavior and learning how to accommodate each person’s unique characteristics.
Unfortunately, is not easy to provide a mathematical function that proves the described techniques success. I can only rely on empirical data for now. Maybe I can expand this a little more in the future. At least, I have learned to know me a little bit more after all this experience and I stopped (re)writting my own API’s. It should worth something!
Let me know your thoughts in the comments section below, or tweet me at @radcortez. If you’d like to read more of my blogs, just click the button below!