From the side I watched a project crash - mainly because the project manager allowed (encouraged?) key people to leave, replacing them with similarly skilled developers who had no experience on the actual project. A previously highly productive development team started to languish and falter - missing deadlines an killing morale; a downward spiral from which the project could not recover. In software development this is a fairly common scenario - particularly when developers start becoming cheeky and demanding (although we would never do that).
Some professions and industries are more able to handle the replacement of one person with another with little or no impact to the job being performed. Semi-skilled workers and tradespeople are good examples, but even highly skilled mature professions can handle it with relative ease - the medical industry even uses the term locum to refer to 'a person who temporarily fulfills the duties of another'. Of course, from an HR or pointy haired management perspective it would be great to be able to treat developers as resources that can simply be interchanged as if they were perfectly fitting parts of a well oiled machine. Managers tend to think 'Hey, this guy knows C# so we can use him to replace that other C# person' - how many times have you heard that?.
As much as software developers think that they are special, the inability to interchange people is not unique to software development. With any job there is a period of lower productivity when someone is replaced. There are many reasons that can be applied to many jobs, from simple things like not knowing where the photocopier is to soft issues of being new and untrusted within a team to more complex reasons such as new skills that need to be acquired and the ramp-up time to understand new processes, terminology and organizational structures. I would imagine that any manager would be familiar with these sorts of issues and most managers would concede that replacing anybody, developer or not carries a certain overhead.
However, development is a fickle art and for the unaware managers there are some issues specific to software development that need to be considered.
The developer may not know much that is relevant
The frameworks that we work with these days are huge, broad and continuously evolving either directly from the vendor or from third party suppliers. It is virtually impossible for a developer to know, at a detailed enough level to be productive, the entire framework or technology stack. So when a developer makes it through the interview process as, say, a senior Java developer, you need to consider what that means in terms of your particular project.
Given a set of 'things' within the framework, an a subset of 'things' that the project needs and the 'things' that a particular individual knows...
If you are very lucky the developer knowledge will overlap quite nicely with your particular project needs...
but unfortunately it is likely that the developer will be a touch out of sync with your project...
and the effort to move the blue circle to cover the yellow circle is costly, painful, time-consuming and often fruitless.
Developers aren't as interested in the clients' business as you may think
Developers are continuously pulled in to meetings with business - sometimes to take a beating for issues and sometimes because people think that if the developer is in the session then properly documented requirements are unnecessary. In these meetings a normally quiet developer will say something like "Well actually, you only need to re-order pink widgets if after they have been dispatched to the DC as they are the only ones not yet at the outlet otherwise you will have to cancel the order and issue an IBT" - a stunned audience instantly appreciates the developers insight into the business issues and the deep understanding that the developer has of their business. But it is only perception - the reality is that at some point the developer had to cater for this undocumented exception(al) scenario in order to get something working. The understanding that he/she has has come from experience rather than a fundamental desire to understand how to move various widgets around the world.
Developers, when they start out in their career are keen on understanding how business works and over time those that maintain such interest go the business analyst route or become assimilated into the SAP consultancy market. Senior developers, although they have a lot of experience across various business processes, are more interested in how the code works rather than the business. Very few top developers can have the same passion for business and development.
Yet, because of the occasional insights and business comments that are expressed by developers from time to time, management is under the impression that the developers are very interested and keen on the real business issues - a fair deduction from someone who doesn't understand the code at all. Developers may monitor hundreds of technical blogs daily, but none relating to the actual business. Developers buy books on the latest technology, but never on, say, the latest thinking around operational risk management. Developers know the business issues because they have to code them up and understand how it all fits together - it almost soaks in over time rather than being studied or aggressively pursued.
When hot-swapping developers, this knowledge about the business simply walks out the door - much the same problem that one would have with any person in the organization with experience. The difference with developers is that it takes time, effort and inclination to rebuild the business knowledge. Think about the last developer that joined your project, maybe they read the requirements document briefly until their network login was set up, but as soon as they could logon and open the project they delved into the code, permanently shelving the requirements document as they started working on the system. They in turn would implement rules in code, not comment them and never reverse update the requirements document - something that their replacement won't even notice.
Googling the code
When developers need to find out how to do something, it is easier to Google for an answer than it is to ask the person sitting at the desk next to you and we have not yet progressed to a stage where the code for a system, that is already easily accessible to all, can be Googled for solutions. Yet at the same time, the chances are pretty high that the problem trying to be solved has been implemented already elsewhere in the project code, particularly if a strong architecture is used with patterns that everybody follows.
Over time, after writing his own code, debugging others' code, figuring out who to blame when the build is broken and so on, the developer starts to gradually build his own internal index of where to find things. Solutions then become simpler, such as - "How should I authenticate against the report server? Go look at the authentication for the web service which is in the WebSvcController module. Ah, good idea!". Sometimes a developer will do a find on the project source code for a keyword that seems unrelated buts points her in the right direction.
When hot-swapping developers, that code index and search engine walks out the door, and the new developer has to re-index all over again - the common result is a few re-inventions of the wheel until the index becomes searchable.
Losing the argument
In the Infomet methodology the loss of an argument refers to the problem in business analysis where users may give their requirements and understand the first models produced, but as the design progresses new terms and abstractions are added and they don't recognise the final design - they cannot argue the correctness of the final model. In software development a similar process occurs where changes are made, code is refactored and layers are added to a point where it is barely recognisable and particularly difficult to understand if the developers weren't along for the entire journey.
Any feature evolves over time and it is the most critical ones that evolve the most because of their importance and usage. Take any simple feature like pressing a button on a form and a new page appears - the first feature complete iteration may be quite simple and have little code; then it is decided to add some authentication and security; perhaps there is a need to add some threading to improve responsiveness; a refactoring process decides that some code behind the button is useful and it is refactored into another library; another similar feature comes along that could use the functionality if it was abstracted correctly. What you land up with down the line is a secure, threaded, refactored, abstracted feature - and it seems perfectly logical to the existing developers, who can also debug, re-use and find their way around the feature anyway, so they don't notice the complexity.
A hot-swapped developer will walk onto a project, take one look at the code the code and think "This is too frikkin complex, I think I need to rewrite it"
Hot-swapping vs Replacing
The idea of this post is not to state that developers are so precious and replacing them is too difficult and detrimental to the project. Developers can be replaced and indeed should be replaced - you may, for example, choose to replace the initial developers with developers better at maintenance as the system stabilises as part of your normal SDLC. Replacement however starts with the premise that the right skills need to be found, formal handover needs to take place and the process of replacing an individual is carefully managed.
Additionally, project managers should endeavour to have little or no high dependency on a particular individual and having a 'High Bus Factor' is a bad idea on any project. This post serves to point out some of the development specific issues with considering developers to be easily replaceable as long as they have X years of experience in technology Y on their resume.
I sincerely hope that more project managers begin to learn that the term locum simply does not apply in software development - yet.
Simon Munro
simon - at - deliveryfocus - dot - net