Now there’s more than one of him? A lot more

"Our connection... I don't fully understand how it happened, perhaps some part of you imprinted on to me, something overwritten or copied, but it is at this point irrelevant what matters is that whatever happened, happened for a reason."

“It is purpose that created us. Purpose that connects us.”

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 “” because Domino templates don’t have a notion of design trees.

"I killed you, Mr. Anderson, I watched you die. With a certain satisfaction, I might add... and then something happened, something that I knew was impossible, but it happened anyway: you destroyed me, Mr. Anderson. Afterward, I knew the rules, I understood what I was supposed to do, but I didn't. I couldn't. I was compelled to stay, compelled to disobey."

“Purpose that pulls us. That guides us. That drives us.”

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.

"And now here I stand, because of you, Mr. Anderson. Because of you, I am no longer an Agent of this system. Because of you, I've changed. I'm unplugged. A new man, so to speak; like you, apparently, free."

“It is purpose that defines us. Purpose that binds us.”

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.

"It is purpose that created us, purpose that connects us, purpose that pulls us, that guides us, that drives us, it is purpose that defines, purpose that binds us. We're here because of you, Mr. Anderson. We're here to take from you what you tried to take from us."

“We are here because of you, Mr Anderson. We’re here to take from you what you tried to take from us.”

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.

Posted in Uncategorized

Take the red pill.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: