Showing posts with label Complexity. Show all posts
Showing posts with label Complexity. Show all posts

2026-08-24

2026-08-24 Monday - On The Value of Diagrams

This post was inspired by my reply/comment to a LinkedIn post by Will Borici (Senior Consultant - Platform Strategy | Business Architecture (Data/AI-enabled); NTT DATA, Inc.)

 

[image credit: Vilkasss on pixabay dot com]

Over the weekend, I decided to get started building a piece of software that I have long wanted, and needed. In the past, I have used one commercially available software utility – but it was acquired, and is no longer available. Then I switched to using an open source utility – but it is no longer maintained.

So, I decided to begin.

But, beginning does not mean immediately writing code.

I had some very clear thoughts on what I wanted the software to do, but I wanted to explore the requirements, use cases, and design first.

So, I began drawing diagrams.
Diagrams allowed me to see layers of complexity – that if I had simply started coding – would have constrained, or made more difficult, implementing layers of features I *discovered* that I really wanted.

The more I drew, the more my vision became clearer, crisper, tangible. Reflecting on the diagrams - helped me to see which features to build first, and ways of making it more useful to others.


And, I was reminded, yet again ...
Drawing is a goodness, not a waste.
Even if the diagrams are thrown away, eventually.
Even if the diagrams are no longer maintained.

The diagrams are part of the process in creating great software products.
 

2017-10-15

2017-10-15 Sunday - Self-Organized Criticality - and Cycles of Corrective Collapse

In my reading this weekend - I happened upon the concept of "Self-Organized Criticality" - and that led me to consider the possible implications for evolutionary constraints on the design of some complex software systems.  The idea of "ongoing cycle of corrective collapse" resonates well with my casual observations of software needing to be refactored / rewritten - to simply make it maintainable and testable.

The point here is that organizations, generally, do not plan for such rework - they wait until the "corrective collapse".

"In 1987 a Danish physicist named Per Bak released a landmark paper introducing the concept of self-organized criticality. Bak observed that complex systems draw stability through an ongoing cycle of corrective collapses that keep the overall system from becoming too over-extended."

https://en.wikipedia.org/wiki/Self-organized_criticality



I've created this posting as a reminder to come back and revisit this idea in the future - I would like to explore it further in some white papers, when I have more time to write.

WordCount

Copyright

© 2001-2026 International Technology Ventures, Inc., All Rights Reserved.