Reusing code is often harder than you’d think. Sometimes the decision not to reuse a piece of code but instead to write new code to do the same thing is not just a case of ‘Not Invented Here’ syndrome but is more a case of trying to ‘Use Someone Elses’ and finding that the fit isn’t quite right…
Writing code that’s reusable is hard but that shouldn’t come as any great surprise. Writing code that is usable is hard; making that code reusable is even harder. Reusing code on Windows in C++ is often even harder as the component that you want to use needs to be compiled in a way that’s useful to you (single threaded? multi-threaded? static lib? Dll?) and the code that you want to reuse needs to be compatible with the code that you want to use it with. The more complicated the interface and the more dependencies that the code brings with it, the harder it is to reuse. If the code uses STL in its public interface then you need to make sure that you use the SAME STL as it does. If you’re using STLPort then it needs to, it can’t use something else as there’s only one
std namespace… Often the most reusable code uses only the lowest common denominator types in its public interface for just this reason; you’re stuck with
char *s rather than
std::strings but at least you can use the code.
I mentioned earlier that we’re building a new component on firm foundations. This necesitates deliberately not reusing code sometimes. The code may be available but it’s not necessarily reliable or reusable enough for us to use as is. The client wants to move towards a higher quality, more testable, code base and to do that we need to cut our links with the past and deliberately decide to NOT reuse some components.
For quite some time, I’ve been of the opinion that ‘Enterprise’ reuse should follow the sourceforge route. Rather than having some ivory tower type deciding that ‘BlahBlah’ project’s ‘XLib’ is the One True Way to do X within the ‘Enterprise’ and that everyone should use it because It Is Good. XLib should be made available with source and documentation within the organisation and if it works for projects it will be used and grow; if it’s a crap design a buggy implementation, poorly documented or too slow for such and such an app then it will wither on the vine. More likely, people who can fix it will fix it, perhaps it will fork and become a new library and others will use the new version to do X because it actually IS good. Internal “market forces” will decide which code is suitable for widespread reuse because it will be reused… The better documented, more reliable, better designed stuff should win through because it will be easier to use.
The alternatives don’t work; too often the One True Way is shite ;) and using it shackles the success of your project to the owners of the libraries that you depend on. Some people are, rightly, concerned about using third party software when you dont have access to the source code because you can find yourself stuck with no support and no way out of a problem. Reusing internal libraries from other teams is often even worse as they’re less likely to provide the support, documentation and future development that an external third party might be able to supply… It’s not their job, their job is writing X business apps not supporting the users of a library they use. Even when you have teams of people who do nothing but provide reusable code for the rest of the Enterprise it’s hard to deliver quality code that suits everyone’s needs; you need good people and, generally, good people will tend to want to be nearer to the action so that they are appreciated by the business users (and, in banking, get bigger bonuses…).
So, Open Source within the Enterprise, you know it makes sense ;)