First, let me give some context for when and why I wrote this article. This is an article I wrote in early 2001 as I began to take over executive responsibilities in a small software company. The startup was comprised of three developers where there was much turnover of contractors and employees within software development for team member four and beyond.

As a primary developer/architect as well as a team leader and company partner I developed a strategy that I called productized components. This is a strategy I used to manage scalability of a churning team while maintaining security and an ability for new developers to rapidly understand existing software resources. It also provided a clear delineation for us to find new revenue streams by selling components of our product suite to other development groups and IT departments.

This article is raw, as I’ve left it basically unedited from its initial draft writing six years ago. Please excuse what I consider poor writing and overlook that for some tidbits of ideas that I think are valid.

What is a component product?

The term component product refers to one or more binary components that perform a specific task or related set of tasks. This is a discreet, black box object that is generic enough to be moved without modification from one application to another. The product part of this concept means that after completion, the component will rarely, if ever, require viewing or changing of its internals.

A fully productized component is not just the compiled binary. It also includes full documentation of the interface and any applicable information about how it works internally. Documentation includes proper use, optimization techniques, a description of the external interface, and examples.

Component products (or any component for that matter) must be perfect. This means the control must handle all error conditions, must be optimized to the fullest, all behavior must be known and consistent, all return codes must be accurate, it must have no bugs.

While this article does not discuss source level componentization, all developers in good practice should develop in a componentized, object oriented manner with regard for design patterns. Source level components should be used to compose binary level product components.

Why companies should develop component products internally?

This system also provides security and scalability to your software department in that contract workers do not have an inside look at the most important part of the software. Instead all they have access to are exposed interfaces of the core-productized components. The core software remains protected from theft or change. Only the binary components will be accessible to parties under lower levels of trust. Couple this with a binary licensing system and your core technology remains secure. If you binaries are stolen it will only work if your license is taken, which means your corporate name and licensing information remains with the binary.

How to build a productized component

For a component to be successful there are certain requirements that must be met:

1. Advanced planning
2. Ability to stand alone
3. Proper documentation
4. Consistent behavior
5. Virtually no bugs!

Benefits of components:

1. Reuse of legacy code
2. Internal security
3. Manageability
4. Upgradability

Core components, and actually any component for that matter, must be perfect. This means the control must handle all error conditions, must be optimized to the fullest, all behavior must be known and documented, all return codes must be accurate, it must have no bugs.This seems like a tall order, and of course it is rare that software of any sort of true magnitude has no bugs. But in the componentized model the components must be small enough that they can be developed so they are near perfect.

This is a must because components are used in binary form; other developers cannot debug them and fix them. If a developer is using a series of components to create something bigger, it is expected and a must that if any bugs or inefficiencies arise it must be a given to the developer that the bug occurs in the code integrating the components and not the components themselves.

If a component is being implemented as the documentation describes then it should behave consistently, without hiccup, without surprise. If the component does contain an error then it is a nightmare for the developer integrating the component. It is difficult to determine that the component is at fault because of the trust given to the component and the mindset of the developer that black box controls should work, period.

It is important to spend most time debugging, testing, and assuring that components behave consistently and as documented. There must be no surprises. If a component is written poorly it’s a given that the application using the component will be poor.

I cannot repeat this enough: components, especially core, productized components, must be perfect because it is difficult for an integrating developer to identify the problem if it is in the component and not it’s implementation. There is no source available so the only recourse for the integrating developer is inefficient: to contact the supporter/developer of the component for cooperative debugging.

So test, test, and test again. Have multiple developers outside of the group who developed the component to review it, have them look for optimizations, bugs, logic flaws, memory leaks, and anything else that’s worth fixing. Sometimes new eyes can see the obvious things that the original developers eyes are used to seeing. Many times the reviewing developers will have different and more efficient approaches due to more experience or more knowledge of an API or something of that sort. It is very important to get many eyes on the code to look for improvement points and to always test, test, test after any change has been made.

What type of programmers build and use productized components

When it comes to the management of manpower productized components can provide a much clearer delineation of work than otherwise possible. With a productized component approach there are at least two categories of workers. First, the high skilled personnel who design, implement, and maintain the core productized components. The second category is the lower skilled labor that can use the productized components to build additions to the application.

The cons of productized components

Productized components take a longer to implement and must be developed by higher skilled developers. While the completion of a task can be done by a certain level programmer the ability to architect a generic implementation in the form of a reusable component requires a skilled, experienced developer.

The process of developing the component also takes more time than simply completing the task. The component must be thoroughly researched, be well implemented, and be tested even more than a solution. A component must be perfect for all cases and not just for the case of the specific implementation.