Inventing The Wheel

There is consensus that 'we should not re-invent the wheel' in anything that we produce. This needs stating more precisely. In approaching any problem we will consider the following approaches in the order presented:

1. Use an existing solution. If someone else has already solved the problem and it looks as though (after due consideration) the solution is open, stable and likely to endure then we should adopt it.
2. Subvert another solution. If someone else has a mechanism that looks like it might solve the problem we should approach them and ask if they would change it to support our needs. Many standards organisations are keen to embrace other areas of endevour and would be willing for us to participate in improving their standard.
3. Extend another solution. Existing solutions often have formal extension mechanisms. If we can solve our problem by extending an existing architecture (after due consideration) we should do it.
4. Copy another solution. If another organisation does something well but their governance does not meet our requirements or we feel we need more control over the technology then we should consider copying someone else's solution (Copyright and IPR permitting and giving due credit to the sources).
5. Create our own solution. As a last resort we should design something of our own.

-- RogerHyam - 24 Oct 2005

I believe that there are advantages to combining bits from various solutions, each of which is a partial solution. When strictly following the above-given reasoning, none of xml/html (sgml already existed), xml formatting objects (CSS already existed), etc. should ever have been created. And you could argue that none of XLink, XForms, etc. should exist, and that they rather should extend than attempt to replace existing mechanisms. -- Gregor Hagedorn, 12. April 2006