What's troubling our PM

Wow, it's almost February and I have not rant nothing yet this year (yeah yeah, double negatives yada yada yada). I must be getting soft. Anyway. Here's a quick one:

PM says: We must move fast

The rest of the gov says in order to move fast you have to:

1) Fill in form A, D11 and E

2) Write a 50 page business plan (anything less will be rejected)

3) Make 10 copies of said business plan plus 3 soft copies burned to DVDs (plain CDs will be rejected) marked "Moving fast program"

4) An Excel file stating the projection of profits for the next 10 years (yeah yeah, we know you made those numbers up but we really enjoy playing with Excel)

5) Should not have a prototype - if we as much as smell the flatulence of a prototype, your proposal will be rejected

6) 6 certified-true-copies of your SPM certificate (why 6 copies... well we just made that up ). BTW, only the Ketua Kampung at which your school was situated would have the authority to certify those copies.

7) 7 copies of your IC (again, must be certified true copy - again, we made the number 7 up... wow this IS fun).

8) Satu dulang hati nyamuk

9) And don't forget, stamp duty RM 10

10) You should have never ever fail before. What? You got third place in that 'Lari dalam guni' competition at kindergarden? Next!!

Recurring patterns in application II : Streamlined object modeling to the rescue

I'm still on my quest to find basic patterns in most (if not all) software systems [read my first attempt here] when I stumbled upon Streamlined Object Modeling (SOM) by Jill Nicola, Mark Mayfield and Mike Abney. This book really blows my mind as it answers my calling with a bang! This book is really a superbly good reference book, on par with Domain Driven Design (DDD) and even the GOF book and yet it is so unknown (it was written back in 2002 - I just graduated in 2002 - and it took me all these years to find it). This must be the most underappreciated IT book ever!

The style of the book does not make it an easy read. It is full of Principles (98 of them) and a bunch of Rules (which I did not count). Also, the fact that they put the diagrams on either the top or the bottom of a page (instead of in the middle of a paragraph where you really need to see it) really seems too "academicy" to me. I guess the style could work for IEEE papers but not so much on a book.

Otherwise, the patterns shown in the book are really Earth-shattering. It echoes back some of the patterns I've suspected in my earlier post. (Which is nice since it does confirm my observation).

Some of the similarities between what I have observed and SOM patterns:

• What I call User is called Actor in SOM

• What I call Context is called Role in SOM

• What I call Event is called Transaction in SOM

• What I call Item is also called Item in SOM

• What I call Item can have links to other Item, SOM qualifies this further by stating the realtionship of type 'Container-Content', 'Group-Member', 'Assembly-Part' and 'OuterPlace-Place'

• One thing I did not capture in my patterns is the Object inheritance part (not to be confused with class inheritance)

Both my patterns and SOM agrees that Events should be fired when properties are changed.

So, why don't I just take the SOM patterns and be done with it?

Well... (oh here it comes)
One of my objective in identifying patterns is to create, at the very least, a GUI generator that will create interface based on the patterns present(instead of just CRUD). That is not so simple with SOM. For example, a SOM pattern always starts with an Actor having a Role and a bunch of Transactions are associated with the Role. This represents the subject-verb relationship in which Actor-Role represents the Subject and Transaction represents the verb. Of course, you must also have the Object part too. This is represented by Item. So, in a SOM setup, you will usually have :



Now imagine that I create (using your off-the-shelf CRUD generator) an interface for this setup, I will have a Role page, in it I have things that have happened (Transactions) and only when clicking on things that have happened that I will have a bunch of objects that I can browse. Which is a bit counter intuitive) There is no concept of direct Item ownership by a Role (or an Actor) in SOM.

Now to mediate this, I can just look at Transaction as a 'wrapper' for Item. From Role I would regard transaction as a see through object and can pierce through it like a glass to see its Items directly. But, would my typical CRUD generator support this piercing? (It does look somewhat like a master-detail setup).

Another problem with CRUD generators is that CRUD generators typically follow DDD, in which you would have DAO (or Services + Repositories in DDD parlance) and GUI codes are created for you in function of your domain model. In DDD, verbs are represented by Services and they are on a separate layer from the domain model. In SOM on the other hand, verbs are modeled as objects integrated with other objects in the domain model. To use CRUD generators with SOM would require a marriage (as if we don't have enough of that already during the last school holidays :) ) between SOM and DDD. Hmmm... how would you do that? For example, in DDD, to create an Item, you would request the repository (which is totally disassociated from your object model) to create it for you. In SOM, a Role, through a Transaction (both of which are intricately part of the domain model) might create it.


Hmm... I will investigate and update this blog again. Stay tune