In the below episode, John is asked about the development story behind VSCode. He responded with two things:
it had to be loosely coupled at the core. They used the analogy of Fiefdoms and Emissaries to emphasize this concept. The lines of separation are truly separations – the code should not leak in terms of separation of concerns, logic, data access, visibility, etc … Design it to be extensible and design it to not leak, because we do not know what tomorrow’s components will be.
Used analogy of downhill skiing vs hiking – fast, fluid, friction-free. Making software dev as much fun and productive as skiing downhill was a metaphor that drove much of the .NET and VSCode development.
I think the loosely coupled is probably the most important design principle in computer science – this is the key to extensibility. Simple IoT does this through its client model:
add data goes through a message bus
clients don’t need to know about each other
Loosely coupled is hard to do if things are overly complex or overly clever.
SOAP-based Web services and the REST architectural style have been and still are the topic of many debates. Many of these debates are heated, often missing the point that the more prescriptive style of the SOAP approach and the more descriptive style of the REST approach have their roots in different scenarios, the former assuming closed worlds and contractual relationships, whereas the latter caters to an open world with ad-hoc interactions [40]. So far, only few attempts have been made to compare both approaches as objectively as possible [31]. “Loose coupling” and “tight coupling” are frequently used terms in such debates, given the positive connotation of the former and the negative implications of the latter. Reduced coupling is beneficial because interdependencies typically make complex IT application systems brittle and slow to adapt to changes [32].
In terms of the goals which should be accomplished when designing service systems, WS-* and REST can be described by integration vs. cooperation (Fiedler et al. [11] make a similar distinction for database systems). Both goals (as well as “loose” and ‘tight” coupling) are not good or bad per-se. They are the result of a strategic decision on how to design and implement IT architectures, and there can be valid business objectives for both of these goals. These business objectives should be the input for a decision how to design a system, for example putting a higher emphasis of performance optimization (usually easier with tight coupling) or agility (usually easier with loose coupling).
This paper was written in 2009. 14 years later, I think we can clearly see the results – REST is still common, but we don’t hear much about SOAP anymore.
