5

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?

Improve this question
3
  • 2
    I think you ought to read the TDWTF article: Patterns of Failure - it sounds like you might be trying to take this company in the wrong direction. Right now it could be perfectly alright that it's like this.
    – doppelgreener
    Dec 4, 2010 at 4:59
  • 1
    I'm afraid you are confusing product strategy (or company strategy) with software development strategy. While it is true that both could be done wrong, and both have the potential to bring down a giant megacorp, each must be addressed at a different level.
    – rwong
    Dec 4, 2010 at 6:01
  • To follow on what actually happened, a software repository was created. Teams were encouraged to add code and documentation for future reuse. There was not much adoption because 1) software not written in a reusable way, 2) no reward/motivation to put software in repository, and 3) software was not general enough to be reused in other projects.
    – Erik
    Dec 8, 2010 at 17:15

7 Answers 7

Reset to default
6

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.

Improve this answer
1
  • The main lesson I learned from this exercise is that you have to plan and design for reuse from day 1. It's hard to retroactively reuse. I think your idea is a good one. Use a successful platform/project core as the building block. I wonder if an Arduino-type model (albeit on a much more complicated scale) might work.
    – Erik
    Dec 8, 2010 at 17:19
3

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.

Improve this answer
2

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
Improve this answer
2
  • 1
    some other points: choose architecture carefully; choose members who have the experience and "almost already know" the right patterns for the project; help the other teams do part of the integration (at least as a showcase, if not for production use); manage expectations; communicate the benefits and risks clearly; respond to defect reports as fast as possible. However, at the later stage of the project, where most teams have already bought-in or finished integration, a hard line has to be drawn to push the remaining teams for adoption.
    – rwong
    Dec 4, 2010 at 8:31
  • @rwong great points.
    – Beth Lang
    Dec 4, 2010 at 16:08
2

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.

Improve this answer
1
  • 1
    an alternative would be to go with reusable components instead of a monolithic library. But good point about the risk of monolithic "not-so-reusable" libraries :)
    – Matthieu
    Dec 4, 2010 at 12:53
1

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.

Improve this answer
1

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.

Improve this answer
-1
  1. become the CIO
  2. promote software reuse
  3. profit!
Improve this answer
5
  • 1
    Such a simple solution!!
    – Manoj R
    Dec 4, 2010 at 11:01
  • 1
    Simple but hardly helpful...
    – Walter
    Dec 4, 2010 at 12:38
  • @Walter: Reality check. Changing the behavior of a large company must come from the top.
    – Steven A. Lowe
    Dec 4, 2010 at 15:48
  • Understood. The hardly helpful part is #1, become the CIO.
    – Walter
    Dec 5, 2010 at 12:46
  • @Walter: (a) it's a joke, (b) step 1 emphasises the often nearly futile effort of trying to change the behavior of a large company from the bottom
    – Steven A. Lowe
    Dec 5, 2010 at 14:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.