Circa 2005, using XML and XSLT to generate HTML was all the rage. It was cool. It was the future. Anyone who was anyone was using it to accomplish all-things-web. If you were using it, you were among the elite. You were automatically worth hiring for any programming-related task.

Overly complex UML diagram

Back then, Richard was working at a small web development company. In this case, "small" means the boss, whoe was a bright guy, but who had absolutely no knowledge of anything -web, -computer or -technology related would make all decisions relating to hiring, purchasing technology and creating technology procedures.

Although Richard was trained as a developer, he had been doing some integration work on small client web sites while the company pursued bigger goals of developing a web portal framework that would allow them to pump out dozens of web portals. To help with the overall architecture, the boss hired an Architect who specialized in intelligent transactional agents. One of his claims to fame was a system he had previously built to map data to presentation HTML via XML and XSLT. The boss was impressed by his understanding and use of these technologies, and based almost entirely on just that, hired him.

The architect spent several months analyzing the underlying data and all the state transitions that would be required, as well as the target HTML into which it had to be morphed. Then he spent several more months coding up the framework. One of the key pillars on which this framework was built was the extensive use of XML and XSLT to convert all the data into something a browser could interpret to render.

When the consultant began to integrate his work with the rest of the infrastructure, lots of little problems started to pop up. For example, source control was really just copying the source tree to a dedicated directory on one developer's laptop. When the consultant had to deploy his latest jar, he would copy it to a network share, from which the developers would copy it locally to use it. However, at some point, the moving of the jar file became significantly less important than the using of the contents of the jar file, and the bug reports began to pile up.

This particular application was basically a corporate directory categorized by region, commerce-type and category/sub-category/actual-category. There were 13 regions with about 4000 businesses, 4 commerce-types and about 300 categories. Any experienced developer would expect that searching for a specific business in region A, type B and category C would be quite fast. It would be reasonable to expect the query to complete in far less than one second. In practice, when all criteria were used, the web server timed out most search queries at 30 seconds.

Apparently, the consultant decided that every little thing should be its own class. No matter how small. A data object containing a Date was insufficient. No, there were separate objects to hold day, month and year, all of which were wrapped in a MyDate object. Ditto for time. Ditto for day of week. Ditto for everything else you could imagine. Then, to really test the capabilities of the IO subsystem, network and silicon, he would query every record in the entire database, construct objects for every component, sub-component, sub-sub-component, and so forth via Hibernate, and scan the list using the slowest possible mechanism in the Java language: instanceof, to see if an object was of a particular type before attempting to use it for purposes of comparison. To make matters worse, it repeated this entire process three times for each query; once to check if each business was of the proper instance for the region, once for the commerce-type and once more for the category.

Richard replaced the whole thing with a simple stored procedure that ran in less than 100ms.

Having dealt with that, Richard and peers told their boss what they went through and asked him to fire the consultant. He agreed, but only after the consultant would modify his framework to support multiple portals on the same system.

After two weeks, the consultant proudly proclaimed that the system now supported as many portals as they wanted. The procedure to enable this capability was to copy the entire project and rename it for each additional web portal.

Having ripped out all of that framework, they never even got to try out the part of the framework that morphed data into XML to be XSLT'd into HTML.

In the end, everything that the consultant did was trashed and rewritten by Richard and his peers in about a month.

Upon reflection, Richard learned that just because you have knowledge of how to use one tool doesn't mean that you are an expert in everything. He also learned that an otherwise intelligent boss can make really stupid decisions if he doesn't have the requisite experience in the relevant field.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!