Dedicated personnel are required to reuse components

I don't know how your company is. At least in my current company, code reusability is very poor. The same module is repeatedly developed among multiple project teams. Even different versions of the same module are also developed by different people in the same project ...... we put a lot of time on repetitive work, so we can't talk about any innovation, because there is no time.

We sincerely hope that one day our work will be like building a building. We only need to design and buy the relevant materials to assemble them. It cannot be imagined when every brick should be built in person.

As a common developer, I may not be able to change the reality. However, if you are a supervisor, you may have to consider it.

Component reuse requires a managerpaul Harmon Archive
Visit the Paul Harmon archive for the complete collection of all past bottom line columns.

Most companies are blundering into component development without a clear plan. that makes sense, when you consider that senior managers don't usually focus on technologies. they focus on results. today, most companies are focused on the Internet and on developing e-commerce and eBusiness applications. to facilitate the development the new B2C or B2B applications, companies decide to adopt java, buy EJB application servers, or rely on MTS and COM +. depending on the tools and servers they buy, they may acquire some components for reuse. if they do, however, those components are already implemented as com or EJB components.

Making quick decisions and moving fast may solve some of the short-run demands that senior executives are placing on it, but it won't prepare it for long-run success.

The first step to planning for it success is to recognize that the move to e-commerce and the Web is in fact a software technology transition. of course it is also a business process transition and of course senior executives are more focused on implementing ing new eBusiness processes, but that doesn't change the way the CIO and senior IT managers shoshould look at the transition. when you start using ob Ject-oriented versions like Visual Basic, C ++, and Java, you are moving toward object-oriented development. when you start developing COM + and EJB components and acquire an MTS or EJB application server, you are committing your company to component-based development. once you face this fact, then the question that follows is: are you going to do it right, or are you going to try to blunder your w Ay through a major technology transition?

"Are you going to do it right, or are you going to try to blunder your way through a major technology transition? "

Assuming you decide you 'd rather do it right and master component-based development, you need to begin by creating a new job position. you need a manager of component development, and he or she needs to report to the CIO or to the manager in charge of software development. put another way, your manager of component development needs clout and he or she needs to be located high enough to have a comprehensive overview of what the organization is doing.

The manager of component development shoshould not be responsible for developing component-based applications. your whole IT group will eventually be developing component-based applications. the manager of component development shoshould be responsible for two things. first, he or she shoshould be responsible for planning the transition. second, he or she shocould end up managing the group within it that is responsible for Reusable Component resources.

In effect, once an organization commits to transitioning to component-based development, it shoshould begin to move toward an organizational structure that divides those who create and maintain reusable components and those who assemble components into applications. moreover, until you have this kind of organization, and some component resources to reuse, You can't practice original tive component-based development. without it, you create a development team to create a new e-commerce application from scratch. the team decides on a language and an application server and then creates a design and starts creating components. they may buy some components from the server vendor or an outside resource, but usually they are under such time pressure that they don't have time to figure out how to acquire components for reuse. besides, not being trained or disciplined to reuse components, most find it easier to create new components than to work through the significant learning curve that the transition to reuse necessarily requires.

"It's rarely a matter of simply taking a component that was developed for one application and using it in another application ."

The only way an organization can get ahead of this game is to appoint a manager of component development and assign that person to manage the transition. the new manager will need to choose his or her targets carefully. first there will be staff training and an evaluation of just what component resources exist. usually it's a matter of identifying some components from outside sources and other components that will need to be developed internally. typically, someone will propose that component x (Personnel Record Update, part order, account, or some such) is frequently used and ought to be standardized for reuse. it's rarely a matter of simply taking a component that was developed for one application and using it in another application. instead, at this point our manager of component development will begin to acquire a team of component developers who will specialize in creating, testing, and maintaining components for reuse.

The component development team will need special skills and they need to be isolated from the contingencies that make it hard for people working on specific projects to take a long range perspective. the component development team is charged with building a library of reusable components. they will buy some and develop Others, often starting with existing components but typically modifying them qui Te a bit. there are lots of issues these developers will face. do you design components in the abstract (UML specifications) and then implement them in specific languages as COM + or EJB components, or focus on implementations right from the start? How do you test components? Who is responsible for approving changes in the components and how do you control versions? Figuring out how to develop and manage component resources will take time.

"Team Managers will need to be educated to require and reward reuse rather than the rapid development of code ."

Then, once the manager and the team feel that they are on top of that, they, or others, will need to train the actual application developers in the reuse of existing resources. this will also take time. team Managers will need to be educated to require and reward reuse rather than the rapid development of code. individuals will need to be available to help developers design applications to take advantage of reuse. its never the case that all of the components needed for an application can be reused. it wocould be impossibly inefficient to aim for such a thing. the key is recognizing what elements of an application can be handled by reusable components and what will require one time development.

I don't want to try to lay out the entire transition here. the key, however, is a manager of component development, and a group that is focused on acquiring, creating, and maintaining reusable components. when I critique an organizations and find a dozen component development projects underway, each trying to figure out how to handle the various problems they face without any high-level help, I know the Organization hasn' t figured out what its doing yet. it has blundered into a major software transition without realizing it or planning for it. one or two teams, by shear hard work and individual brilliance may produce a great e-commerce application. but the company isn't ready to systematically duplicate that effort when it seeks to create another eBusiness application. nor will it be ready to modify that and other applications as new technologies and eBusiness processes emerge in the years ahead.

On the other hand, when I visit organizations and see such individuals in place, I know the company has thought about what it is doing and has a transition plan. with a little luck, the organization with the manager is going to get better and better at systematically creating component-based applications. and, at the same time, I need CT they will start to raise the time and cost of application development while simultaneously increasing the quality of the applications. they have a plan to take advantage of what the component transition really offers.

<! -- End text --> <! -- Discussion bar --> <! -- Discussion bar -->