Develop for reuse

As a tech lead, on occasion I’m faced with the question:

• How well should something be implemented? Is it OK if it just works, or do I need to refactor and make it more “generic”?
• When is it done?
• …

The rule I live by is as following:
If I write code, I make it so that I, or anybody else, could reuse that code with ease.

This means:

• Write good documentation, mostly on WHAT it does, not HOW. It’s a whole lot easier to read code if you know what the result should be. It’s not easier to read how something works, then read the code and then guess what the desired outcome should be.
• Write clear code. Hacks or fuzzy lines should be refactored. Hacks tend to get more hackish with old age.
• Create loosely coupled code. Code with a lot of dependencies can’t be reused. Make it a little more abstract if you have to.
• Use generic names. Don’t write classes named MyProjectDataValidatorUtils.
• Don’t hard code project specific stuff. Use property injection instead.

This does NOT mean:

• Write code that can do a lot more than is needed for the project.
• Premature optimization. If I know my project will only have 10 entities, I’m not testing for a million…
• Over document it. We are still developers. Write to many and you won’t really read anything at all six months from now.

If done a handful of projects and I reuse a lot of stuff from old projects. The fantastic thing is, that these building blocks have the tendency to improve over projects. Every project needs specific functionality, and by adding those to existing blocks you end up with some really powerful, reusable parts.

Regards!
Andries