When I proposed in my last entry the idea of putting your XPages and Custom Controls in just one place, Thimo expressed concern over the number of design elements that could end up in such a beast of an application. And his concern is completely justified. Attached here is a screenshot of the custom control list for the IBM Teamroom template for Domino 9. I don’t mean to pick on this template; in fact I consider many of the people that have worked on it friends. It’s just that it perfectly illustrates the Notes-style of development that is so ill-suited to XPages.
There are 92 custom controls in the Teamroom template. Because of the structure of NSFs, they aren’t organized into packages or directories. In fact, they can’t even be organized into modern namespaces like “com.ibm.xsp.teamroom.setup” because Domino templates don’t have a notion of design trees.
Part of the problem is that people tend to equate code with capabilities. “If there are 92 custom controls, then this application must have a lot of features!” I make this mistake all the time, too. “Hey look, there are 1500 Java packages available in the XPages runtime!” “The Extension Library provides over 120 new components!” “This software package has 2 million lines of code!”
But more code is only good if that code exists for a reason. It must have a specific purpose to justify its existence. Code that doesn’t have a specific and necessary benefit goes from being an asset to a liability. It becomes something that has to be tested and maintained for the sole reason that it’s already there.
If we were to describe something that consumes resources and energy without a specific benefit in biological terms, we might call it a parasite. Or a virus. Or a cancer.
Cancerous code is incredibly common in the Notes world. It grew out of the frictionless ease with which developers have always been able to create copies. Want to create a new app? Copy an existing template, crack it open, and have at it. Want to grab a library or an agent or a form from another application? Right-click, copy. Right-click, paste. Want to duplicate a function from one library to another? Ctrl+C, Ctrl+V.
And what are the code management tools available on the classic platform? Replication. Templates. Element inheritance. The server Design task. The Catalog database. Far from providing a solution to the cancerous growth of code, these tools feed it, encouraging the strategy of duplication rather than reuse.
As a result, present day Notes shops make David Lynch’s The Elephant Man look like Olivia Wilde.
As a demonstartion of this tragic tendency for Notes code to swell like a tumor on an application, I’ve attached a series of 3 images that show 4 of the custom controls for the “AllDocs” group in the Teamroom template. I’ve taken screenshots of the first page of the source panes for these controls, and overlayed them with various degrees of transparency. When you look at them, notice just how little is different from one control to the next. What differences do exist are not structural. They are in the values for attributes of identical components across the controls.
Of course, you shouldn’t just accept my image examples. Open up the template for yourself and have a look. Compare the controls to each other and ask yourself why these are distinct controls with independent requirements for testing and maintenance.
If you can come up with an answer better than “habit,” I’d love to hear it.