Does 1 developer equal 1 developer?
When a developer is brought in to a project, most managers believe the developer will automatically start writing code and understand the system. Today, I discuss why that isn't so.
Most businesses believe that if they lack a programmer with a certain skillset, they outsource the job to a programmer or group of programmers. It doesn't matter if it's in or out of the country, consultants or new employees.
When a new developer is brought in and introduced to a new system and asked to maintain it, they struggle.
With the amount of "creative coding" applied across the hundreds of thousands of systems, managers expect a developer to pick up where the other developer left off.
As I've said before, all programmers "paint" a different image on their digital canvas. Writing code is no different than painting for artists.
It may be more abstract than what another programmer is used to, but their creativity sometimes makes other programmers tilt their head like a dog hearing a weird sound from their masters and the developers start twitching because it's not what they're used to seeing in code.
The amount of knowledge or skill for one developer may not be the same for another. As a matter of fact, if a new programmer is introduced to a new system, the amount of work is based on four criteria:
-
How much does the developer know about the system?
Joe Schmoe is considered an entry-level developer and cannot provide the same value that Joe Elite just gave to the project because he just designed the entire application. -
How much business knowledge can the developer apply to the system?
Does the developer have previous knowledge in this line of work? Did he/she/they work on a similar system somewhere else? If not, there needs to be a ramp-up period for the new recruit to understand what the client is looking for and how the system works. -
Can the developer get along with team members?
If a new employee/contractor is added to the team and the team starts to bicker instead of being productive, it may lead to a disaster for the project down the road. As the old saying goes, "Too many chiefs and not enough indians." -
Is the developer a novice, intermediate, or advanced programmer?
If someone doesn't know the difference between a flyweight and singleton pattern and the project uses patterns, I think Joe Schmoe may seem a little overwhelmed with the project. This criteria should be addressed when interviewing individuals. - Are there unit tests for a developer to get up-to-speed?
Nowadays, developers document their code by writing code. How so? By using Unit Tests. These unit tests describe the functionality of what the system is meant to achieve. It also shows the pathways into the system and how it's expected to work.
Even though one developer replaces another developer, it does not mean the project will be successful or fail miserably, but it does mean that it may extend the length of the project. Usually, the amount of work required by one developer multiplies by at least 2 when a brand new developer is introduced into a new system.
I've seen companies take this route and they expect the developer to hit the ground running. Give the developer ample amount of time to absorb the requirements, design, and technology of the system before expecting the developer to perform the assigned tasks.
One developer does not equal one developer.
Have you experienced other criteria when outsourcing a project or brought in a new developer? Did I miss one? Tell me about it below in the comments section.
