Broader applications of your ideas

[Lukas]

Hi John,

since your book is titled a philosophy of software design, I'm curious on what your thoughts are on broader philosophical implications of applying software design principals to complex systems - which I find your book to be in a sense.

Do you see concrete applications in other areas of science or is this "just" interesting technical wizardry?

I appreciate you,

Lukas

[John Ousterhout]

Hi Lukas,

I haven't given a lot of thought to the issue of whether/how the design principles from APOSD can be applied more broadly, but I suspect that at least a few of them can. For example, I think the idea of deciding what is important and focusing the design around that is at the heart of good design in all domains. On the other hand, it's harder to see how to apply ideas like "comments should document things that aren't obvious from the code" in areas outside of CS.

-John-

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/software-design-book/CAKP4UA1%2BA%2BBV-avtdaVR4e8ghXy7%2BpQ%3DxQ86gm17QHrcDQGd%3Dw%40mail.gmail.com.

[Tim Etler]

I've been thinking about this a lot. I think the philosophy behind the book can be applied to pretty much any information system if you think of communication as information flow and as an interface. I think you can view a company as an information system where data flows through a bunch of interfaces. Email, chat channels and messages, meetings, epics, stories, PRs, PRDs, build systems, they are all ways information can pass from one part of the system to another, and if you think of them as interfaces, you can apply the same theory of complexity from the book to organizations too. More broadly it can apply to any system where information flows which could include science as well.

I view it as being the basis behind Conway's Law of because if you view the communication structure of an org as an interface, that means the interface of the org is creating constraints on your designs the same way a programming interface will put constraints on the rest of the software system built around it.

From that perspective I think you can apply the same lessons about managing complexity for software to communication systems of an entire organization to create a holistic view of the information architecture that takes into account how information flowing impacts everything from teams to project planning to the actual software you write.

You can think of different levels of communication as different levels of information abstraction and information hiding. A team hides the complexity of the project planning within the team from other teams. An epic hides the complexity of the individual stories to make milestone tracking easier to conceptualize for managers. Stories hide the complexity of the PRs that complete them. PRs hide the complexity of the individual commits a developer wrote while implementing the code.

Because it's all connected and influenced by each other, I think there's a lot of opportunity to optimize information systems if you think of them through the lens of interfaces and what information is communicated and how you can refine that communication to reduce cognitive load and choose the right abstractions that can help you manage complexity or redefine it out of existence.

[Venkat Dinavahi]

I think this principle applies to product thinking as well.

For example, if you have a product that is easy to use (simple interface) but hides a lot of complexity (gives you back a lot for that simple interface) you are likely to have a very successful product.

You constantly strive to make this product easier to use and deliver more value without complicating things.

When you're designing software systems, the product is the API design and the user is yourself and other developers.