Symptoms

---

Even more problematic than the illness is the fact many developers overlook that the problem exists, which does not allow preventing or curing NIH (Not-Invented-Here) Syndrome. To get around this, we first look at the symptoms that indicate the existence of the illness and why it is a problem. Only then can we move on to fixing the problem.

Control Fanatics by Nature

Programming represents a creative process that produces a deterministic result; in other words, the results of programming are usually predictable and therefore controllable. At least that is how it is perceived. Because of this, there is a tendency for the profession to attract those who desire more control over the product of their efforts. Programming offers a level of control that is not possible in the random world of nature. This tendency is enforced by the benefits a controlling personality brings to software development. Process and attention to detail are required to complete software projects on time and on budget.

However, perhaps a better description for many programmers is control fanatics. The very personality trait that helps in many respects can be very destructive in certain areas of programming. Obviously, one such disadvantage is embodied in NIH Syndrome. The desire to avoid using other programmers’ code is at the core of an attempt to avoid losing control. Most programmers exhibit this trait to some degree, and will often take more work upon them in order to maintain control of the code. This is not to say that this is an entirely irrational behavior, but that there are better methods for handling the situation than avoidance. In order to understand how to change the thinking patterns related to NIH Syndrome, it is essential to understand why programmers are reticent to give up control of the code base.

What Are We Afraid Of?

Fear is a fundamental driving force of human nature, so it is not surprising that it manifests itself even in the logical world of software development. As with many other aspects of life, fear serves a useful purpose in avoiding disaster, but the cost is paid by the occurrence of misdirected fear. This type of fear is caused by a misunderstanding of the cause and effect of a situation, and it brings about actions that are in reality unneeded or even harmful to the desired goal. It is therefore important to distinguish fear from risk management, where fear is a condition brought on by a lack of information, and risk management is the analysis of information to determine the correct practices to avoid. With this in mind, let us look at some fears about using external code that do not fall under risk management. Later we will look closer at the valid points that these fears do raise, and how to properly manage the risk that the rational part of these fears represents.

Performance

One of the most prevalent reasons for avoiding third-party code is the concern over performance. Programmers are not likely to admit that code they did not write will perform adequately. However, before we even deal with this issue, a more important reason why performance should not be a concern is dealt with in the Premature Optimization illness. To summarize, performance should only be a concern at the end of development or under special circumstances before then, and optimizations should not be attempted before gathering profiling information to determine where optimizations are required. For a more in-depth discussion of why this is and how to prevent it, refer back to Chapter 1, “Premature Optimization.” This principle should be applied to external code in addition to internal or personally written code, hence its relevance to NIH Syndrome.

The other important point to keep in mind when deciding whether to fear third-party code is that you cannot be an expert in every aspect of software development. Some third-party libraries and frameworks are developed by experts in the field they operate in, making them more likely to be complete and efficient than a non-specialist programmer could possibly do for the same price. Take advantage of this when possible and concentrate on the areas where your experience is best used.

Sound Decisions

One of the most overlooked disciplines in the interactive entertainment industry is sound programming. This is often given as a side project to any programmer with free time. This programmer often has little or no real experience with sound programming, and is even less likely to understand sound theory and design. This caused problems for one typical project that was targeting the PlayStation 2 console system. Several programmers worked on the sound system, but this task was only one among many that they had on their plate. Without the time or expertise to concentrate on the sound system, the project ended up with a simple yet still bug-ridden sound implementation as the project drew near completion. Although the bugs were removed, which took a considerable amount of time, the sound system still ended up being simple and unimpressive.

Another project decided instead to use a third-party sound implementation created by programmers dedicated to understanding and implementing advanced sound on the PlayStation 2. While it still took time to integrate the library, there were fewer bugs and more features. This not only saved development time, but it also gave the end user of the product a richer sound experience.

Learning

Programmers are often afraid that they will have to learn a new system and new concepts that will take time. Some do not want to do this, while others fear they will be severely side-tracked and stop being productive as they pursue only the learning experience. While these points are valid, avoiding the use of outside code so that you do not have to learn the interface is a manifestation of fear rather than proper risk management. To bring the issue back into the realm of risk management, we need to consider how to manage the learning experience to balance the need for using the new code with the time spent learning how to use the new code.

Some might still be reticent to learn new concepts, feeling that they can manage with their current set of knowledge. This is a disastrous line of thinking for a programmer. If you are one of the ones who want to stop learning, you might want to consider a career change. The world of computer science is in constant flux and the rate of discovery continues to accelerate. If you have trouble learning the new concepts at the rate necessary, it would be beneficial to get some training in how to study properly, but if you simply do not want to do the learning, then you will need to evaluate how you expect to compete in the industry.

Missing Features

Another common fear is that the third-party library will be missing a feature that you require later. Software development is an uncertain process that can easily spring a surprise on an unsuspecting programmer at any time during development. Therefore, it is certainly possible that necessary features will be missing from external code and libraries that were acquired earlier. However, the feared result of this is usually blown out of proportion to the actual impact. Most often ignored is that if this feature were not present when evaluating the third-party code, it would also not have been included in the regular programming schedule if the third-party code were not used. This means that there would still be schedule consequences to this oversight with or without the external libraries.

At this point, an obvious argument emerges, saying that it is more difficult to add a feature to other programmers’ code and therefore it will take more time anyway. This is certainly true, but the impact can be offset by the time saved in not having to develop and test the remainder of the external code. Thus, it is really a matter of evaluating the potential risks and the corresponding reward potential rather than taking a single risk out of context. In addition, we will later look at some techniques to improve the speed with which fixes and features can be taken care of for third-party libraries.

Debugging

It is hard enough to track down your own bugs, so it is natural to fear tracking down bugs from other programmers. What if you use a third-party library and it has an error in the code? Since you didn’t write it, the error will be hard to find. The time spent looking for it will be wasted when you could have been doing useful work. Moreover, what if you don’t have the source code, how will it get fixed at all? Maybe you should just forget about using external code altogether.

Now that we have seen the path fear can lead us down, let us consider what the tradeoffs are and then decide. First, if you must develop functionality yourself there is a guaranteed overhead versus using existing code. How much this makes a difference depends entirely on the code and its complexity. Next, and more important, when you write the code yourself, it will have bugs as well and since it is in-house will have a smaller test base for working those bugs out. Suppose you had to spend two weeks learning a third-party library and another week tracking down a bug in the library, for a total of three weeks. That might seem like a lot of time, but then consider that to do it yourself you spend a month writing it, and another two months testing and debugging it. This is a common example of the real tradeoffs involved. As with all decisions, it is dependent on context, but the odds favor already written code. Later, we will talk about how to improve your chances with proper methods for choosing and integrating external code that will reduce time spent debugging.

Deadlines

One of the primary reasons why we worry about learning a new system and debugging it if something goes wrong is missed deadlines. Except for a small percentage of the industry, software development is primarily a commercially driven enterprise. This means schedules to meet and milestones to complete. Perhaps in the past, you have experienced schedule delays caused by the use of external code, or missed a milestone because of a third-party library. Even if you have not experienced this personally, you are likely to work with someone who has suffered from this very situation.

However, it is a mistaken notion to solely blame the use of external code and libraries for these problems. A common scenario that can cause problems goes as follows. You approach the project manager and explain that a set of sound libraries is available from a commercial sound software developer. Since your team needs that functionality, you ask if you can purchase the library for use on your project. The manager gets excited, approves your purchase, and sends you off with the necessary paperwork. He then looks at the project task list and removes the sound implementation task, since it is already written by a third party. Suddenly, you are expecting to finish everything a month sooner. Unfortunately, it takes two weeks to get the library integrated with the application and bug free. This causes the next milestone to be missed. The lesson to take away from this is not that using third-party code is bad; instead, realize that it is not a panacea and requires proper scheduling and risk management. Treated properly, external code is no more likely to cause missed deadlines than internal code.

What Should We Be Afraid Of?

On the other side of the coin, there are things to fear if you do not take advantage of available code and libraries. The symptoms that you will inevitably see are what you should really be afraid of because they guarantee the loss of time and money on a project.

Duplication of Code

If a solution already exists, and you implement it again yourself, you are guaranteed to be creating similar code for the same task. This is a waste of resources unless there is some substantial benefit the new implementation has over the one that was already written. As we just discussed, many of the common reasons why people believe the new implementation will be better are not as concrete as they first appear. What you are usually left with is lost programming time and an implementation that could have been integrated much earlier. Additional time can easily be lost waiting for the new implementation to be completed and tested.

Worse yet, if use of third-party libraries and code is not coordinated properly, some programmers on a team might use one implementation while others write their own. This leads to maintenance problems and other errors that are common to the Cut-and-Paste (CAP) Epidemic. To avoid this, use of libraries and external code should be openly encouraged so that it can be maintained and coordinated. Fear of third-party code will only lead to poor communication and hence a corresponding loss of control over code duplication.

Lists represent a very common algorithm that is duplicated by multiple programmers on the same project. Occasionally, projects even go so far as to have an implementation for each individual list. Many third-party libraries also have their own lists. Applications can end up mixing custom lists with several different third-party lists. Look through your application and see if this proliferation of list implementations is occurring. Now think about how much developer time was spent learning, implementing, and maintaining each of these lists. If instead, the project had settled on one implementation, such as the Standard Template Library for C++ or the Collection classes for Java, this time could have been better spent elsewhere and the risk of error would also have been reduced.

Duplication of Work

Duplication of code implies duplication of work and effort, but that is not the only source of duplicated work when all third-party solutions are rejected. There is also a duplication of testing and debugging effort involved in getting it working. This is handled to one degree or another by the original developer of the code. In addition, if the library or code is popular, there might already be a wide base of users. They are implicitly doing their own testing and debugging, saving you time and effort.

There is also the research time required to choose the proper data structure and algorithms. This is often overlooked, even during internal development. Chances are, if you are working on something internal, the time to research it has not been scheduled. This leads to quick and often inappropriate solutions that require revision later. On the other hand, a middleware developer making products for other developers has a real interest in spending time to make their code use the best algorithms and data structures for the job. Even if a mistake or two is made, these are often corrected if you are not the first customer to use their product. As you can see, there is a lot more time and resource considerations involved than the simple writing of code.

Is Third-Party Code Better?

The era of the Renaissance man is long gone and unlikely to reemerge soon. No longer can one person be knowledgeable in all areas of science, or even a subset of the knowledge such as computer programming. In order to create the structures of the modern world, real or virtual, it takes a group of people who each have their own specialty that they understand in detail. Therefore, it is likely that you will not be able to provide all the expertise your project requires.

Third-party libraries and code can provide a vehicle for this expertise. Developers of code meant for use by other developers are likely to seek out the most experienced programmers in the field in which their code will be used. Because they generally have a narrower focus, this knowledge is maintained and improved at a rate not possible with the distractions of other programming tasks to worry about.

---