Not Invented Here or just Not Usable Here?

| 3 Comments | 1 TrackBack
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 necesarilly 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 ;)

1 TrackBack

I was reading Len Holegate’s blog and came across his article Not Invented Here or just Not Usable Here? (nice post Len!).

In here, Len p

Read More

3 Comments

Interesting point about 'open sourcing' code within the 'enterprise'. My only reservation about that is that it certain companies they do tend to take on graduates who have read Stroustrup, and that's about it. So they'll make changes to code they think is 'correct' (e.g. your comments about singletons) but that has to be reverted by someone. I think it's a good idea. We have lots of people external to our group (sort of) working on our code. It's quite easy to find the person that did the 'wrong thing'.

I guess someone still has to police the changes.....

Yes, you'd need people to police the changes. I'm thinking more along the Linux kernel style rather than the random open source project that forks all over the place style. The main point is that the groups that are depending on these Enterprise libs could have someone involved in the maintenance of them rather than just hoping that the team responsible do the right thing.

I have covered the 'policing' isssue in my post : "Enterprise Open Source - but is it the answer?"

I have never liked the term 'policing' in this sort of context however... and prefer 'governance' and especially "accountability"...

...JHMO...

Leave a comment