Principle 73 in Alan Davis’ 201 Principles of Software Development discusses the need for loose coupling of software components. This is a ”known unknown” that bears repeating. Services composition remains a bit of a black art, and the key to successful application integration.
No matter the profession, the size of the cubicle or the number of stops you make, you may find a reference book you tend to take along the way. For hardware engineers it may be something like Donalds Fink’s and Donald Christiansen’s Electronics Engineers’ Handbook. For many project managers it is Fredrick Brooks’ The Mythical Man Month. In my case, I have carried 201 Principles of Software Development along through more than a couple of career incarnations.
In this 1995 book, Alan Davis compiles good bits from many Structured Design and Analysis era software development books – yes, Fredrick Brooks’ writing is well represented – to form a useful set of succinct software development principles.
In last week’s Advisor, my colleague James Denman wrote about Decoupled Service Contracts and services modularity. Since then, somewhat randomly, I came across Principle 73 – ”Use coupling and cohesion” – in 201 Principles of Software Development and by chance it was on the topic of coupling and cohesion. This write-up pre-dates ”service-oriented architecture” – but it still vividly relevant. Sizing software services for integration remains a challenge.
Davis writes that coupling and cohesion were defined in the 1970’s by Larry Constantine and Ed Yourdon in Structured Design. At the time, coupling and cohesion were seen as the best measures of software system maintainability and adaptability. Coupling was the measure of how interrelated two software components were. Cohesion described how related one component’s functions were to another’s.
Constantine and Yourdon prescribed high cohesion and low coupling as the best objectives. Note that they didn’t use the term ”loose coupling” but that was the goal they were pursuing. They write:
”High coupling implies that, when we change a component, changes to other components are likely.”
Davis notes that from the time of “Structured Design” onward, most books on software design described these measures. ”Learn them. Use them to guide your design decisions,” he advises.
Like the general adages of publisher Poor Richard (Benjamin Franklin), fabulist Aesop or baseball pitcher Satchel Paige, many of the design principles of 201 Principles of Software Development are so obvious that they need to be regularly repeated. Software is hard. A set of principles helps you cope.
Do you have any software integration or development principles that have stood you in good stead? Send them to SearchSOA.com Editors. Provide a phone and email address as well, and your name will be entered in a drawing to win a book from the SearchSOA.com software book library.