What performance maniacs need

by Warren Gaebel | May 31, 2012

In Pete Markiewicz’ March post, he suggested that the web-design community should create a database of code snippets, boilerplates, and/or design patterns. The purpose is to make high-performance code available to all. We would just find the solution we need and drop it into our application. I first came across the concept of off-the-shelf, drop-in components circa 1990. IBM’s brilliant Chester Buczek caught the vision and was telling me all about it. I was working in a PL/I – DB/2 – mainframe environment at the time. Chester’s concept caught my attention because it included not just the use of off-the-shelf components, but also pipeling the output of components into other components. Yes, Chester’s concept was promising, but it never happened (well, not universally).

Why Pete’s Concept is Sound

The big benefit, especially from a corporate viewpoint, is the level of reuse. Whether the repository exists at the company level or is universally available, plugging existing code into an application will likely take less time than reinventing the wheel. If managed properly, it may improve correctness and performance, too.

What Else Do We Need?

Why didn’t Chester’s idea catch on in the 1990’s? I didn’t really follow it, but I can hazard a couple of guesses. Let’s hope these aren’t show-stoppers for Pete, too.

•  Marketing: Someone has to get the word out. No matter how good something is, people can’t support it if they don’t know it exists. Over the decades, many entrepreneurs found out the hard way that the old adage — “if you build a better mousetrap, the world will beat a path to your door” — is false.
• Administration: Someone has to build the database, provide metadata, keep it running, add/replace code, record scores, and take care of all the minutiae. Beyond mere administration, the project requires leadership.
• Copyright: The perfect sharing licence continues to elude us. There are many different ways to share without surrendering intellectual property, but nothing makes everyone happy. Only the public domain is acceptable to everyone.
• Scoring: Providing a score for each piece of code in the database will be done by a group of experts or by the community as a whole. If handled by experts, they will want to be paid. If handled by the community as a whole, what will stop it from becoming nothing more than a popularity contest? A popularity contest is not a good way to establish performance scores.
• Initial Training: Individual developers need to learn how to use the database, but training takes time and money.
• Choosing One From Many: If the database provides multiple solutions for the same situation, users will have to wade through long lists of solutions, compare them, evaluate the best ones, and make a selection. The more solutions there are, the harder and more time-consuming this task becomes. The ideal is to have one and only one solution for each situation, which is sure to turn into a nightmare of political infighting.
• Acceptance: Everyone needs to be on board. The smaller the community of users, the sooner we reach end-of-life on the project.
• Indexing the Database: A database requires a search engine and/or some form of indexing. Users want to be able to find a solution in a reasonable amount of time. The project requires indexing and search algorithms that are specific to this unique database.
• Funding: No surprise to see this one in the list. Who’s going to foot the bill?

Who Should Spearhead This Effort?