Imperatives for setting a goal

What are the factors you'd consider before setting a goal for yourself or for the people who work for you? Apparantly, the answers would be purpose, time frame, execution plan. If these are your answers, you are close but not perfect.

An axiom for setting a goal is RUN which stands for Realistic, Understandable, and Necessary. This sounds very simple and is very elusive and we often overlook it. The explanation for RUN starts with the last character..OK..OK alphabet, I'm engrossed in Software, as always :-). A goal is marked as necessary if it has a purpose/value, is time boxed. Next is Understandable, ensure that the purpose is clearly understood and your or your team's role is clear so that the execution plan is drafted accordingly. Finally, the goal would be realistic if it has well drafted execution plan.

RUN concept is not just limited to software projects. Infact, the concept has been borrowed from the manufacturing domain. Managers, if you want your teams to gain velocity and run, do not forget to apply the RUN concept when you do the estimations next time.

The Dark Art of Transaction Management

Ask the folks on your team "Who can define transaction management?", expect to see only few hands raised. The number would still dwindle if the question were "What is the transaction strategy used in your application?". This is the reality. Another interesting thing is people treat XA as a panacea. Mind you, it is going to become a resource hog if used improperly.

I came across a recent presentation on InfoQ titled "Transaction Management Strategies in Mission Critical Applications". A good presentation with indepth look at the transaction, its demarcations, management and usage. I highly recommend all the fellow developers/architects to go through the presentation. I particularly liked the myths of transaction management, a quick summary of myths and realties:

Myth1: All mission critical enterprise apps require XA transactions
Myth2: Transaction O/R Mapping integration requires XA/JTA
Myth3: For combining JDBC and JMS access, XA is necessary

The realty is that many enterprise apps do not require XA at all. O/R Mappers just operate on the DB connection with some cache housekeeping that does not require XA. The last myth is the common situation in many applications. I have seen this misconception in a recent project. This can be avoided by using JMS with local transactions or with the acknowledgements.

There is a free book on the InfoQ site - "Java Transaction Design Strategies" by Mark Richards. Use transactions, especially XA with care, otherwise you need to pay the price once application is in production.