There are over 200,000 web development companies and IT service companies registered on Clutch. The count of companies not registered on Clutch is even more. With so many options it is no surprise that businesses bounce their web development from one source to the next all the time. Somewhere someone is facing this situation right now as you are reading. So how do you successfully inherit a job you didn’t start? For those who are yet to figure out the best possible way to deal with code shifting from old to a new developer, read on…
Asking a new developer to work on an old developer’s code is like asking a cook to continue making a dish that the old cook has left unfinished. There’s so little time and the customer is waiting on the table. The new chef has to figure out what ingredients are in the dish, how much more time it needs in the oven, and what more needs to be added.
If the restaurant follows the same recipe for the dish, the new cook knows exactly what ingredients are required, and if the cook is experienced he/she can figure out the ingredients already added and ingredients required in the dish. But cooking is often unstructured, much like development is.
The Dish here is the code
The Recipe is the coding standards
The ingredients are the functionalities
The job is to make the customer/client happy with a good dish/product. The point that the restaurant follows the same recipe every time eases the pressure off the new cook. A good check can quickly go through the recipe, taste the half-finished dish, and figure out what needs to be done. A delicious dish has a good artistic touch of the cook and a scientific touch of the right ingredients added at the right time. Coding is both art and science flavored together.
Maintained Coding Standards Help the New Developer
So how does all this food talk relate to transitioning a web development to another developer? A lot of how successful a transition goes comes down to documentation. Documentation can give the incoming developer an idea of how things are coded, where things are, and what does what. If the outgoing chef left notes about what ingredients and the recipe they followed then the incoming chef should be able to service customers just as well. Documenting code with clear comments, using a consistent philosophy, following common patterns all projects are some ways to maintain your coding standards.
Marketers follow styling guides for their marketing assets. The right font, size of the titles, color code, and formatting of the pages are all part of their content styling guide. Every team member knows this and can easily identify it whether working on the project from scratch or taking over from the middle.
Similarly, there are coding style guides for the development ecosystem. There are numerous styles, rules, recommendations, documentation styles for each programming language out there. There’s no right or wrong in there. But, once you choose to work on the coding standard, stick to it so that every developer can understand the code regardless of who coded it first.
That’s the thing the agency as a whole needs to take care of for a smooth project transfer from one developer to another. The part we are discussing next is important for the new developer to cover, just like the new cook. A responsible cook won’t leave the customer stranded or put the restaurant’s reputation at risk.
Why blaming the old developer's code is not always good?
Computan has been in business since 1987. During this time we have been fortunate to work with a lot of different customers, and of course, we have had relationships with customers end and change hands. In many situations, we have been asked by our replacement provider to answer questions, provide training or assets for them to service their new account (and our outgoing one). Yes, obviously project managers don’t find this fun. Change is never easy. However, there is a tacit understanding amongst good developers that on some days your transitioning new accounts in and others you are transitioning old accounts out. Regardless there is a time-honored tradition among good developers to make yourself available during the transition. Ultimately, as savage as it sounds, how you exit a project or phase yourself out becomes the legacy of your relationship on that project. Regardless of why your time developing on a project ends and there are ill-feelings or whatever if the new developer is able to take the ball and run with it fairly quickly that speaks to how good a job you did.
On the topic of the new developer. The new developer must understand what’s at stake here and should not indulge in the blame game. In thousands of agencies with even more project-based different scenarios, managers often hear the new developer blaming the old developer. Or the code gets all the shaming. It is also the easy way out for the new developer to not to look in another developer’s code. In the developer community personal attacks are amateurish. Also, it doesn’t give the employer and the employee a good start. But, everything is not dark with code-blaming there’s an upside as well if it is genuine and done analytically.
The good side of code blaming. What good comes out of it?
The upside is that if there are genuine errors in the code or the old one is a bad/poor/outdated practice, you should listen to the new developers. They might bring in some new and improved ways to do things. Welcome and respect the different perspectives. And, if that changes the development practice in your agency for the better then why not consider it?
In the marketers' world as well, the styling guides often change from time to time. For example, with the mobile revolution, brands changed their font style and size for comfortable reading on mobile devices. The only constant in the world is Change. A new developer bringing an improved and better change in the coding standards must be heard.
Analyze the new suggestions. If there’s room for improvement, you know you’ve got the right new joiner. See if they bring a positive change in the current system or were they just making excuses for not working on the old code.
You would know which way to go by then. Whether working on the old code and fixing the errors would be beneficial with changing the coding standards from the next project. Or there’s still time and scope of bringing the change at this stage of the current project.
Agency life is a here-today, gone-tomorrow sort of life. Turnover is high and contractors are tested and replaced very quickly. Agencies always wonder about bringing on a new developer and replacing an old one. I hope this blog helps you identify the right choice to make when you are in the middle of this dilemma.