Archive for April, 2009

Clear design, clear code, clarity for the developers

Monday, April 27th, 2009

I keep stumbling upon Schema's that I have a hard time Architects (of external companies, btw) seriously thought of bringing 'into the wild'.

For example consider the following:

You are building a service (like a webshop) where people can BOOK certain items, and they can also CANCEL certain booked items.

What do you see in the design here?
What "codes" would you come up for the status of bookingresponses of your service?

Of course, you need to know what you want to support. Bookings might not be confirmed at once, so apart from 'confirmed' status, there is also a 'confirmationpending' status.

And what if bookings get cancelled? well the status can than be 'cancelled' or 'cancellationPending'

Some Architect thank thought of the characters to represent these four things.

1. BookingConfirmed
2. BookingConfirmationPending
3. CancellationSuccesfull
4. CancellationPending

What did the Architecht come up with?



So what is "C"? Does it mean Cancelled or Confirmed? I really do not know, every time I see the C in the XML message, I have to look it up…. and than it turns out to be Confirmed instead of Cancelled… *sigh*.

Message: Do not f*ck up. PLEASE come up with a reasonable architecture… Why use a "C" and why use an "X" FCOL??? Would "BC" (for booking-confirmed) and "CAC" for CancelConfirmed not have been just a tiny bit easier?