Monday, March 30, 2009


Google Reader.  One of my favourite tool which enable me to aggregate some of my favourite source for information.  It has also expand my horizon to the vast knowledge and information out there in the Internet.

One of my recent addition to my Google Reader subscription is Jeff Atwood's Coding Horror. Through his blog I also picked up so very interesting blogs such as Eric Lippert's Fabulous Adventures In Coding.

An interesting read I got recently from the blogs originates form Eric Lippert's Five Dollar Programming Words: Orthogonality.

My first experience with this word is probably in introduction to geometry where the word means "at right-angle".  However this word in the programming or IT solution sense really ring a bell with me.  

Recently, on my consulting gig, I was working on a solution to a business problem which was very "difficult".  Difficult not in the sense which the solution is difficult to understand nor was it difficult to implement.  I didn't quite get to the bottom of the root cause of the problem until this five dollar word so succinctly puts it.  The solution to the problem lacks orthogonality.  

In other words, a small change to a requirement or approach often leads to changes in other use-cases or other areas of the solution.  Unfortunately, I think I am at the point of no return.  I.e. there is no time to go back and re-work the approach.

Nonetheless, this word really had a profound impact to my approach on problem solving and designing a solution.  Next time around, I would spend much more time and emphasis on improving the orthogonality of a solution.

Introduction to the Credit Crisis

Great introduction to the credit crisis: The Crisis of Credit Visualized.  Probably an over-simplification, but nonetheless, a great introduction.

Joel's Big Macs vs. The Naked Chef

I have been working in one of those IT consulting companies that Joel commented on in his article Big Macs vs. The Nacked Chef and I couldn't help nodding my head in agreement while reading his blog.

Most of the time, I whole-heartedly agree with Joel's points.  However this time around, I had to disagree with him on the whole notion of Beware of Methodologies.  I worked in one of those companies which these methodologies are created and taught. It is a great way to standardize the lingo across geography and a diversed workforce.  After studying the methodologies and the tools around, it is pretty clear to me these were written by some very smart people.  One of those tools I am glad I got a chance to used is the estimators.

Even though the estimators are written in, god forbid, excel and vbscript, the out-come of the tools was a excellent framework to work within to estimate projects.  Each field has their own estimator and each estimators are different.  No doubt some are better the other, nonetheless it is one way to put structure into the art project estimation which I argue even the most talented programmer, project manager or genius can gain some benefit from.

I want to emphasize this one more time: these methodologies and tools are merely framework or guidelines.  I.e. if the methodologies list any deliverable which doesn't make any sense for your particular project, document exactly why it doesn't make sense to do it, and don't do it.  The estimator is even a better example of this.  In the custom application development estimator, it list every activity in the custom application development methodology.  In the custom application development methodology, it list every activity in custom application development known to man-kind.  By default, after you enter all you inputs to the estimator, the estimation is going to be insanely huge!  This is normal.  The next step in the estimation phase is to go through the tasks, assess the client's needs, and rationalize their needs against the tasks.  Scale back the task estimation if it is too had, drop it if it is not needed.  Bottom-line, work with the client and document the decisions on scaled-back or drop task.

More often than not, even the smartest person cannot forsee everything, or he/she assume it does not need to be done.  It is often the aggregation of a missed task here, a wrong assumption there which cause consulting projects to fail.  In other words, these methodologies enable people to learned from other's past experience.

Don't get me wrong, these methodologies are by no means perfect.  In my opinion, these  methodologies are a great framework to work within.  The problem is not the tools or methodologies itself, but the people using them.  The not-so-talented people often treat these tools or methodologies as the "Silver-bullet".  Instead, they are merely guidelines or frameworks which one could work within.  It is not an end, but merely a mean to achieve the end result desired. 

After all, it is garbage-in garbage-out and there is no black-magic or cure for that.

Sunday, March 29, 2009

Immutability vs Readability - The Spring bean injection method question

I have worked with Spring for awhile on the side, as a pet project, and something just to try out. Not until recently, did I get a chance to use it in an "Enterprisy" environment. I didn't quite expect this discussion to ever come up, but I was genuinely impressed when a manager actually brought up the topic around the approach to spring bean configuration.

SpringSource recommends configuring Spring beans using the constructor method. This allow the beans to be immutable and immutable objects improves the orthogonality of the code.

The manager on the project said the company recommends bean configuration through properties. The reasoning she provide is improvable readability. This is true since reading the spring configuration of beans injected through constructor does not indicate which "property" is being set. However given the integration of today's IDE with spring, one can quickly look up the source code to determine the property being set via the constructor. If a third party library is being used, IDE these days are also tightly integrated with javadoc where you can quickly look up the parameter you are setting too.

Given all the advantage of immutable object and improve orthogonality of the code, I would strongly suggest this out weigh the "inconvenience" or "decrease in readability" of the configuration file. I am a big highly orthogonal code or system, but this is a topic all by itself for another post. For now see Eric Lippert's blog on orthogonality in the context of programming @

Like all things in life, I do think constructor-injection is a rule of thumb. It should be by no means follow blindly. Constructor-injection is hard to read due to the nature of setting via either "Order" or "Type", once you get a certain amount of properties to set and a lot of them are of the same type, it gets really confusing. When you reach that point, it is important which we re-evaluate the original position: Is making the bean immutable worth the price to pay in readability?