Howardism: Thoughtful Consideration better than any Pattern

Comment

Jive Software has released a Jabber API for Java into the public domain. It is called Smack and one thing that struck me was that this library doesn't depend on any other XML library. In other words, they rolled their own XML parser.

Normally, I wouldn't recommend that, as what you loose in performance considerations with dealing with XML in the first place you gain in development time by using already built parsers.

However, in this case, Jabber… er XMPP, is kind of strange in that it doesn't transfer XML documents but XML streams. Sure, this clearly means that DOM is not a good approach, but why isn't SAX? While I haven't talked to the Smack developers, my guess is that Jabber has some obvious use cases that could be optimized by parsing it directly instead of using the SAX approach.

—Howard the Author

Thoughtful Consideration better than any Pattern

I was reading the latest issue of Java Performance Tuning and noticed an interview with Bill Lynch and Matt Tucker, who founded Jive Software, and they make some interesting points in regards to design considerations and performance.

What struck me the most was their "thoughtful consideration" of all aspects of their programs. For instance, even though their requirements stated that they needed to be scalable across clusters, they didn't just choose EJBs-- they answered the requirement.

They also just didn't use standard caching software since they could see their own usage patterns and could gain significant performance improvements by rolling their own.

This is the balance that we all need… between building upon more generalized code (for quicker development and that has usually been better-tested) and creating unique, specialized solutions for performance reasons. It just goes to show that thoughtful consideration is better than the thoughtless application of any design or architectural pattern.

Still looking for a rule? Try this one for size… start with general building-blocks but keep things transparent and your components loosely coupled. Then start looking for usage patterns, bottlenecks, and better implementations and start re-factoring.

I also think that there is a business case for this approach. Your customer gets what they want on time (since you built your code upon the shoulders of other software) and they are willing to pay for performance improvements.

Tell others about this article:

Click here to submit this page to Stumble It


	Whence Jini? Java Not Fun? Freemarker vs. Velocity Loosely Coupled Components, Part 1 Computer Inspiration What's up with Java? Interview Questions Why Not Use the Database? Perspectives on Struts Read other entries in Java...	Comment Jive Software has released a Jabber API for Java into the public domain. It is called Smack and one thing that struck me was that this library doesn't depend on any other XML library. In other words, they rolled their own XML parser. Normally, I wouldn't recommend that, as what you loose in performance considerations with dealing with XML in the first place you gain in development time by using already built parsers. However, in this case, Jabber… er XMPP, is kind of strange in that it doesn't transfer XML documents but XML streams. Sure, this clearly means that DOM is not a good approach, but why isn't SAX? While I haven't talked to the Smack developers, my guess is that Jabber has some obvious use cases that could be optimized by parsing it directly instead of using the SAX approach. —Howard the Author Thoughtful Consideration better than any Pattern I was reading the latest issue of Java Performance Tuning and noticed an interview with Bill Lynch and Matt Tucker, who founded Jive Software, and they make some interesting points in regards to design considerations and performance. What struck me the most was their "thoughtful consideration" of all aspects of their programs. For instance, even though their requirements stated that they needed to be scalable across clusters, they didn't just choose EJBs-- they answered the requirement. They also just didn't use standard caching software since they could see their own usage patterns and could gain significant performance improvements by rolling their own. This is the balance that we all need… between building upon more generalized code (for quicker development and that has usually been better-tested) and creating unique, specialized solutions for performance reasons. It just goes to show that thoughtful consideration is better than the thoughtless application of any design or architectural pattern. Still looking for a rule? Try this one for size… start with general building-blocks but keep things transparent and your components loosely coupled. Then start looking for usage patterns, bottlenecks, and better implementations and start re-factoring. I also think that there is a business case for this approach. Your customer gets what they want on time (since you built your code upon the shoulders of other software) and they are willing to pay for performance improvements. Tell others about this article:
	2014, Howard Abrams Some rights reserved	Originally written on 18 June 2004. Updated on 8 February 2014.