Monday, March 31, 2008

Code Reuse Inside Your Own Company

A short read over on Dr. Dobbs, Where Are the Clients In a SOA? made some good observations about the mindset of creating reusable SOA components, especially when the reuse is likely to occur in your own back yard.

"The best "enterprise architecture" plan will never be realized as long as developers assume the client of a piece of code is another piece of code."
"As software developers we are not very good customers of the work our colleagues do. We are quicker to search the Internet for a utility or example than we are to search our own internal repositories."
"More importantly, we aren't thinking about other developers when we create the code. We don't create interfaces that make it easy for people to use our code in ways we have not considered. We don't provide design-level abstractions that help other programmers and architects fit our solution into theirs. We don't market the code to the rest of the team or to other teams within the organization. We don't do any market research to make sure the nontraditional customers of our code are going to make the most of it. We don't package it in ways that also make it easy to use outside our intended use."
The emphasis is mine, although it should be yours, too.

3 comments:

Kit Plummer said...

Good stuff. So true, and a complete shame. With tools like Koders available for internal use...

However, code reuse (as a problem) isn't going to go away. So I'm not sure the code search engines will last very long. As a developer I just want to see how the library/framework works - and formal documentation and blog posts seem to be the current formula.

As you've highlighted, proper architecture and design of "components" are the answer. Though they've been the answer for at least 20 years.

Having attempted to internalize corporate-source and SOA and at a major defense contractor, I can tell you that this is a huge problem. I do believe platforms like Java are partially to blame. Even inside corporate walls there's no standards for which framework or platform to use (thankfully). So, that makes it even that much more difficult to share code across development efforts. The SOA part helps ease some of this pain as the abstraction of interfaces goes from the language-level to the network level. Ah...I could go on and on.

It is good to see that someone else is seeing the same things that I am.

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...

Good post.