Specifications

I was having lunch with Jeff and Ian at Café Mauro when the subject of JSR168 portlets came up. It seems the architectural strategy at Jeff’s current client is to build all portlets in strict accordance to the specification (JSR168).

A blanket statement like all pieces of software are to be written as absolute deriviates of a specification makes no sense to me. I see it as architectural idealism; a pattern that hinders the movement to build better software. And here’s why.

Specifications have authors and guess where those authors work? They work for the large software vendors of the world. They work at SAP, they work at IBM, they work at Oracle…you get the idea. They co-author these specifications because they want to standardize ideas or approaches to building products. Once the specification is published, they release their implementation of the specification and customers buy it. It makes sense. They add functionality to the published version; some companies do a really good job, some fail miserably. That’s their problem (and their customer’s I suppose).

Let’s use Portal as an example. Here are three reasons why I will never insist my team build onlyJSR 168 portlets:

1. It prevents them from leveraging what they own- They paid for a swack of work done by the diligent developers from their vendors labs…they should probably use it.
2. It slows the software development cycle – Spending my time hand crafting something that has already been built means I’m not hand crafting the stuff that hasn’t been built
3. It severs their support channel – “Ummm, IBM, Hi, it’s Jamie McIlroy calling. Yeah, I’m having some trouble with my real time awareness application within WebSphere…what’s that? Sametime? No, no…we wrote our own to comply with JSR 168…ummm, hello?!”

I can’t wait to sit in a meeting and here someone tell a client they can’t have functionality they need because: a. It’s not part of a rather generic specification or b. It would take too long to rebuild it to comply with the specification. Yeah, I’d love to support my colleague on that one…While I’m at it, I should probably ask the client to stop taking their medication (Drug Companies are corrupt) or writing to their mother. It’s not my place.

WebSphere Portal and it’s proprietary portlet specification (WPI) have loads of good things we’re delivering to the business. Sametime awareness (not in the specification — never will be), Click2Action (c2a, not portlet messaging: not in the specification — never will be) are two examples of helpful function points I have no problem getting out to the business.

This idealism is like asking your home builder not to use any manufactured parts in your new house. Asking them to mill every bannister spindle, baseboard and door jam. While the idea may seem appealing, imagine what it would cost? Imagine how little you’d care about those hand crafted baseboards once you moved in. I imagine telling my wife how the obscene budget overruns are attributed to the hand blown glass windows I had the builder make. Your boss at work is like my boss at home. They don’t care about where it comes from. — they don’t want any surprises. They care that it works and you did your homework before deciding to use it.

---

*This assumes I’m working for a customer and that customer isn’t in the business of writing JSR168 portlets.

Remembering Memory Management with CORBA

Java is a wonderful language, especially when compared to a container native language like LotusScript. There are many more options, frameworks, design patterns you can play with. The tools for writing Java agents make the days of writing LotusScript agents seem like forever ago. Have I discovered the silver bullet in the Domino world? Is this my valhalla?

No.

Not by a long shot. Remember memory management? Yeah, it’s back. I tried writing a simple agent that processed a Domino view containing a little more than 20,000 records. The agent uses the POI framework to convert the view into an excel workbook. This is done on a nightly basis. Here’s the thing. Domino’s default heap size is 64mb. My agent was running out of memory. A simple increase in heap size got me around the issue but raised the concern that memory management is something I now need to keep my eye on when writing these Java agents. I know, I know, any (every) developer should always be thinking about memory management but Domino’s LotusScript lulled me away from the concern.

That being said, I still believe this is the way I’ll continue to write my Domino agents from this day forward. My main reason? I can write junit tests for them. A topic for another day…

Testing Overhead

I was enjoying a sandwich with my friend Lindsay the other day when he asked an age old question:

“How much extra time do you think Test Driven Development adds to the build process of a software project?”

An excellent question, one I think about all the time. Once we established what he meant by build process my answer was pretty easy:

“None”

As a test driven developer, when was the last time you were burned by a NullPointerException? I haven’t seen one in my domains for a couple of years. You catch that stuff at build time through the effective use of testing. You know the state of your objects before they start interacting with other objects.

With some research, I’d wager that Test Driven Development actually saves time. The tests that drive my software were written by a customer. If my tests (and subsequent software) satisfy what the customer has written, I’m done. Finished. I can remember thinking I was done solving the customer’s problem only to later find I didn’t fully comprehend it. When they write the tests and I code them, we’re both aware of their expectations. That saves a tonne of time and better than that, it frees up my time to solve more of their problems.

If you’re new to TDD and looking for a good book to take you through the preliminary steps, try Kent Beck’s Test Driven Development: By Example