The effects of adopting Componentware are radical. Programmers spend less time writing bread-and-butter code. Production is partially accomplished by assemblage.
Radical use of Componentware does, however, mean that your people will be spending more time sourcing and vetting components, liaising with the manufacturers, and fine-tuning the bought-in functions. If you are going to turn the introduction of Componentware into an optimum advantage, don't impose it. You need everyone's cooperation.
In some teams there is a strong culture of the "not invented here/I'll build it myself." The programmers don't trust anything they haven't assembled themselves.
If your people are proudly self-sufficient, you should respect their sensibilities. Call everyone together and discuss the possibilities as an academic exercise. Emphasize your confidence in their ability to produce every item if necessary. Their abilities are not in question. But should you expect the chef to lay the egg?
Raise the question of whether the quality of items you might buy ready-made is compatible with the quality of the product you and your programmers intend to produce. Ask where ready-mades will and won't work. Discuss what opportunities buying-in might create. Remind them lightly that architects have long since given up baking their own bricks just as programmers have long since stopped writing their own compilers. Go through the list of modules required by your program and tentatively ask them to star which tasks might be subcontracted.
Point out that the software engineers will be able to devote more time to the superstructure of the software instead of its foundations.
Acknowledgment is vital. Your programmers are being asked to create many other important things that just can't be bought.
Explain how buying-in may tip the balance of the outcome of the project, particularly if you encounter unexpected snags. If the consensus is that Componentware has certain possibilities, don't let the negatives become a logjam. Get the ball rolling by setting up a small working party to look into some of the more promising possibilities.
Don't rush the outcome. Let the situation, not the personalities, make the case. Think, discuss, and come to a consensus. If the working party recommends that there are instances where it makes more sense to buy ready-made components, you will need to make the entire management aware of your plan to do so. For instance, the costing model charged by the vendor must be acceptable to them. Componenting has failed in the past when management hasn't appreciated its implications.
After you've checked into possible Componentware, step back and consider your software as a sequence of key components. See which ones make the best cases. Fundamentally, you will have to choose between an exclusively tailor-made product and a more quickly produced model, with purchased parts.
Don't fall into the common trap of expecting Componentware to get you out of a hole. Many people try out components for the first time only when they discover they are over budget or behind schedule. Using components has a big impact on the design of programs. They can't be dropped in without planning.
Was this article helpful?