FAQ 28.03 Should application development organizations create their own container classes?

No. Too many application development organizations roll their own container classes from scratch. This is often motivated by the "not invented here" (NIH) syndrome, which is lethal to any kind of reuse.

The problems with application development organizations rolling their own container classes include the following.

• Increased development costs: It's normally far cheaper to pay for a class library than to pay yourself to write your own.

• Increased long-term costs: Building your own means increasing your maintenance costs, which is usually the last thing you want to do.

• Degraded quality: Application developers are not usually experts in the intricacies of data structures, so they often do a mediocre job with container classes reinventing the wheel is bad enough, but usually they reinvent a flat tire.

• Lack of flexibility and versatility: It is hard for an in-house development team to compete with the well-funded software houses in developing software that is flexible enough to meet the needs of the whole industry. This flexibility may be very important later in the life cycle.

• Loss of focus: Application developers should focus on getting the application done on time and within budget, not on plumbing.

• Missed opportunities for standardization: It makes sense for the containers to be as standardized as the basic language types for both training and maintenance considerations.