How can I promote software reuse in a large company? [duplicate]

Question

This question already has an answer here:

• How to promote code reuse and documentation? 4 answers

Take a large company, formed through many iterations of mergers and reorganizations. This company produces lots of different products that are all targeted to a specific industry. Most products share similar characteristics, such as communication standards and certification and safety requirements. But there is no unified development platform or model for the company. Each product has its own distinct hardware, and software is created in any number of languages. Most new products will be updates to older versions or target the same industry. What strategies would you use to promote software reuse?

Answer 1

Given your constraints, I'm not sure software reuse is even a good idea. The teams for your individual products are already intimately familiar with the particular tools and platforms for each specific product, so reinventing them to promote code reuse may be a waste of time and money.

Any reworking of this kind would most certainly involve corporate strategy. You would have to make a compelling case that the restructuring would save time and resources, improve efficiencies, and make the company more profitable.

A simpler approach: If you come out with any new products, you could try reusing pieces of your most successful platform.

Answer 2

I think you need to consider a large company to be for all practical purposes a wild software ecosystem; maybe not so heterogeneous as the entire world but still you'll have to expect that tool and software practices are pretty well diffused.

So the question of how to promote code re-use in the company is not different from promoting it with the world. I am advocating, an essentially open source approach to development of commonly useful components. Let us know if you ever get it to work.

Answer 3

The problem with code reuse is that code needs to evolve differently in different products.

Say that you have two products (1 and 2) that have some similar characteristics, and you then extract a library (L) out of them that contains those shared characteristics. Seems like a good idea: you now just improve the library, and the improvements go "automagically" to both products.

Then, over time, you build more products on top of that library. Eventually you have 10 products. You'll notice that changing the library has become an extremely stiff process. You have to consider all those 10 products when implementing a change, and after you've implemented it, you have to test it on all those products. What if some of the products now need to evolve differently, even though they were kind of similar in the start? You could either branch the library so that different products have their own versions of the library (no more sharing advantage), or start building all kind of switches, options, adapter layers and special cases to accommodate for all special needs in the single united codebase. The end resuld could be a Big ball of mud.

It may be doable, but it's not as rosy as one might hope. At least it increases risk.

Answer 4

A few years ago I actually was able to start a team that did this within the organization I was working for at the time. It was a great experience and I'd do it again in a heart-beat. The most difficult people to sell on the idea were the other developers, not the management. I had a good reputation with the different development groups so that was very helpful and we were very careful to keep that reputation as our team grew. By the time I left the company the project had been alive for two years and had around 8 full time developers.

Advise I could pass on:

• Have a team that is responsible for nothing other than this
• Get your requirements from representatives of each development group so that they have buy-in
• Start with something that developers on a couple teams already want to share
• Document you code as well as you would expect a language to be documented

Answer 5

Don't look for the big revolution - look for small but cumulative evolutionary steps. Look for the opportunities where some positive change is relatively easy.

Don't push the idea so hard you're seen as a crank.

Answer 6

The best way to make software reusable is to make it visible and understandable.

• If nobody knows it exists, nobody will use it.
• If nobody can figure out how to use it, nobody will use it.

For developers this means making good documentation and usecases. I'll discuss Java since that is what I know the best:

Use JavaDoc: This allows for creating cross-referenced API documentation where the skeleton is created automatically and you have well-defined places for putting in HTML-snippets in your code which will then end up in the web documentation. See the official Java documentation for a good example. In my opinion this is some of the best code based documentation available today.

Put the JavaDoc in a searchable place: For people to be able to find it you need to make it public. Have an internal web server where all documentation go to, probably subclassed by project. In a perfect world have a SINGLE web site incorporating ALL classes developed inhouse.

Make it easy to get: Have a location link from which it is extremely simple to pull out the source code (or the library). Eclipse has some mechanics for doing so. Preferably the source from a source repository, as the source repository can TELL who has worked on a given piece of code, giving a good idea of who to talk to in case that you need assistance with that code.

Have good usage examples: The easiest way to show how to use it, is with good unit tests, as they demonstrate how to use the code, and what to expect back. Being runnable they can verify that the code runs as described.

Answer 7

1. become the CIO
2. promote software reuse
3. profit!