First lines of Hammurapi code were written in the fall of 2002. The product changed several names before becoming Hammurapi.

As development progressed, JSEL (Java Source Engineering Library) was extracted from Hammurapi codebase as a separated product. With this extraction the Common library was created to host shared functionality.

Transformica was originally created to generate language element classes from Java grammar. SQLC was created to simplify database access.

When the Common library became too big, it was split into two parts, the Common library per se and the Enterprise Extensions library.

Big number of products and the way they were modified through little iterations lead to the versioning overhead. E.g. modifications in the Common library could ripple through several products. In some products they'd cause public API changes, in other only private changes and in some other they'd cause no changes at all. Keeping track of what was changed was an unproductive spend of time. We solved the problem by creating Build number. This tool manages 3 out of 4 version number parts and it makes life a whole lot easier.

Version 3 of Hammurapi was a great success with dosens of thousands downloads and a number of big corporations using it. User feedback and experience with the tool lead us to creation of  the version 5 and the concept of the Code Governance Platform. Jsel was superceded with Mesopotamia. The heart of Hammurapi 3, DispatchingVisitor, was put on steroids and became Hammurapi rules.

Some of learnings are worth mentioning here:

• A code review tool shall be capable of reviewing non-compilable code. 
• Some developers code around tool findings instead of fixing them. E.g. (1+1+1)*(1+1)  was used to represent 6 in order to circumvent HardcodedNumbericLiteral inspector. What is interesting is that the fix, introduction of a constant, is easier to implement in Eclipse than to come up with this trick.
• Sometimes inspectors shall be chained. I.e. inspectors work in a team and findings of one inspector are fed to several other inspectors. This learning was the key factor which lead to creation of  Hammurapi rules.
• Out of the box review tool inspector/rules are typically of moderate to little value to the customer. If a tool has hunderes of inspectors then their output becomes noise which developers ignore. Inspectors created from bitter experience of production outages are of the most value. Therefore the tool shall provide an effective way to create custom inpsectors.
• The tool must provide a holistic view of an application, i.e. it must be multi-lingual. For example, mo matter how perfect your Java is, SQL join without WHERE clause on tables with millions of rows will kill the application.
• Developers are not the primary stakeholders of the code governance process. This article covers it in more detail.
• In the enterprise environment it is not enough to review code and dump findings to console or a file. There should be processes governing code problems lifecycle. 

Argun, whose original name was XMenu, was created several years ago. It was significantly enhanced in the late 2006 and the first half of 2007.