Contract-First Approach Still

There’s one thing I want to mention about my last post on contract-first methodology.
In service inventory, Entity Services layers might be generated by a tool, as opposite to the goodness about write the contract by hand.

Last century, when I other web developers endeavors were working with JavaScript/HTML, we could notice how different code was depending on the handcraft’s origins (notepad or other advanced tools for that time).

Companies already have their system and database models. Moving to SOA is a strategy that could take years . Advantage from tools could be taken if we do generate contract from database tables and thereafter, and also generate services and users interfaces from those very contracts. For all those legacy work, this approach should be nice.

What a hell, man? You may ask now.

One thing which intrigues me is runtime coupling between objects. When using WCF to generate contracts for your services and the visual studio solution might have many services within. Of course you may want to reuse some comportment instead of creating them when you are build service compositions. But, if you need to change those objects (or contract), you will realize a horrible buildtime coupling problems and you may need to upgrade all consumer contracts instead of just release another WSDL contract version at you service.

Again, balance the situation is good. SOA has to be intrinsically with the financial economies. If the company is already established in its industry and need more power, SOA is a mandatory tool. If the company still about to grow, SOA is an option that the advantages and slows might incommodities.

Coupling & Usability

For the past months I heavily have been researching about improving system design and turn out system coupling problems in many aspects, builds, algorithms, etc.

Let usability comes as another official one.

I got some insights after reading the book The Elements of User Experience, that usability is another key to increasing coupling and system complexity. These things are really connected.

Poor usability leads developers to work without direction. Free to do whatever they want, whatever their experience is leading them to.

I still need to reflect about this as I’ve seen developers complaining about hard devolvement to achieve usability requirements sometimes this could be related to individual experiences.

We’re human; we try to easy things when difficulties come up as we try to avoid new things when we are accustomed to the old ones.