The.Artist.&.The.Code

One of the common problems that plague software companies (and their customers) is the departure of developers. Most of their custom-made software solutions depend on several key developers who knows the code inside-out and with their departure, new (or fresh) developers may not be able to continue the work of the original author.

Many methodologies and strategies have been explored to reduce the reliability on Heroics and focus more on well-managed, repeatable and defined processes. While managers can claim that developers are a-dime-a-dozen where they can easily shop for developers anywhere - both local and foreign, that is really not the case in reality.

In my opinion, a piece of software is equivalent to a piece of artwork and the developer is the artist. Every line of code is equivalent to a stroke of a brush. Therefore, software can never be blueprint products like houses, cars, televisions and etc. This can be observed by a single specification given to 10 different developers and each will produce the software differently yet achieving the stated specifications.

In a manufacturing assembly line, all workers who have the same skills are considered equal and can be easily shuffled or replaced to assemble the blueprint products. However, in software development, there is the added element of artistic talent and therefore, it takes some time for a new developer to understand what the previous is doing before being able to continue.

Some managers may claim that this is untrue because as long as every business logic is documented, it doesn't matter who is the developer. The problem lies in the specification example that I gave earlier. Managers must understand that there is no problem for developers to understand specifications or how a system functions, but the problem lies in developers reading code. Reading documentation is different from reading code.

For example:

foreach(DataRow row in table.Rows)
{
if((bool)row["Include"] == true)
{
// do somework.
}
}

and

foreach(DataRow row in table.Rows)
{
if((bool)row["Include"] == false) continue;

// do somework.
}

are both doing the same thing.

There is actually no solution to this problem of developers leaving because it is common in the industry. However, there are some strategies that can minimize the impact.

Rule No. 1 - Project managers must ensure that developers remain intact in a project until its completion. When a developer leaves in the middle of the project, be prepared to enter an entry into your risk-register.

Rule No. 2 - Organizations should have a plan for scheduled rewrites for their custom-software when it reaches a certain life-span. Patches and enhancements will ultimately cause the software to be unstable or unmaintanable. Rewrites will allow new developers to be trained and opportunities for the software to be enhanced using the latest technologies.

Rule No. 3 - Do not treat developers as commodities. The life-span of your software depends on your developers' turnover rate. The higher the turnover, the shorter your software product life-span and the faster you will hit the rewrite stage.

Rule No. 4 - Do not assume that many fresh developers are better than one senior developer. In software development, the number of developers you have doesn't mean anything.

Rule No. 5 - Develop an architecture. An application architecture is the closest of what you can get for a blueprint in sotfware development. Always, employ a software architecture to plan out the architecture of your applications so that future enhancements can be made easier even to fresh developers.

I hope this article can be useful to aspiring project managers and existing managers. If you have your thoughts to share, please feel free to comment.