Monday, October 09, 2006

C and I, with OOAD

I've never had an exhilarating and enlightening a talk as I had with C, a colleague, a friend, a former officemate of mine who is now the founder-CEO of the Philippine's premier training and consultancy for Java, with whom I had a chance to sit down and talk over the weekend.

C and I met for a possible partnership by inviting me to be one of the resources for his startup, which I gladly accepted.

Anyway, on the technical side. He brought to mind and made it clear to me the distinction between applying (or imposing) OOAD (Object-Oriented Analysis and Design) methodology for enterprise Java systems/apps development. As I have been espousing for quite some time that Java people should be practitioners of OOAD (if they have not been doing that) as OOAD enforces (you guess it right) object-oriented thinking, as opposed to "function(or method) thinkers" practiced by the school of Oracle developers where most of the logic are done in stored procs, pl/sql statements, etc.

However, C reminded me about time to market as an important (and deciding) criteria for an Enterprise Client, which in most probability, looks for quick, easy and visible results. The solution provider then takes to mind that "fast delivery of a working system" is the main key factor for his success, and for a greater chance of having repeat customers or the security of future projects. Thus on the business side, it pays very much to consider the "business criteria" rather than the "technical criteria".

I think C and I, as we went along ranting about OOAD, pros and cons, shared and agreed that
as far as business is concerned, OOAD is not something a solutions provider imposes, but rather
something that his client requires. Therefore, the solution provider must consider best-practices along with "business-success (best) practices".

C has a more introspective take on the subject in his blog

No comments: