People talk about software ossification as being bad, but is it always?
One thing I like about ossification is that you can take the analogy in very interesting directions if you compare the strength of a structure (or software system) by thinking of it in terms of rigid vs flexible rather than strong vs weak.
Rigid structures don't survive earthquakes or other major changes, however all building structures need rigidity or they won't be able to last at all and will collapse.
@hazelweakly Ossification means to become rigid like a bone and honestly something has to hold the gelatinous mess that is much of the software industry up off the floor.
@hazelweakly so - I think it depends on why things ossify. Take Clojure for instance. A deliberate decision has been made and repeatedly affirmed to grow the standard library strictly by accretion. A design objective is that nothing will ever be removed, and the future is achievable by layering. Obviously this locks in all sorts of decisions for ever. Clojure gets away with this because it's mostly functional, so there isn't core state to have to rework. UI libraries f.ex. don't have that lux.
The key, to me is being intentional about where rigidity is, where it shouldn't be, and intentionally including it in thoughtful places so that you can build a structure that's strong enough to have flexibility be introduced.
Whereas if you build a structure that's always flexible you will be forced to make it rigid and you won't be able to choose where.
How do y'all build intentional rigidity into your systems so that you can adapt to change? Let me know!
@hazelweakly very interested in this line of thinking, and it's key to the work I do on platform teams and (internal) technical standardization.
Good example of intentional rigidity is strongly defined interfaces at subsystem boundaries.
Your word "ossification" is interesting as an extended metaphor: bones form on a "matrix" that guides the deposition of minerals and then becomes incorporated into the ultimate structure of the bone, like an internal scaffold.
@juno@hazelweakly This rhymes a lot with the intro of Tony William's "On Inheritance" internal MS memo ca. 1990, which advocated a shift away from the infinite flexibility of Smalltalk systems and towards a sort of "cellular rigidity", or encapsulated flexibility.
The paper is cited by Wikipedia as being "foundational to the development of OLE/COM".
(Linked as a Google Doc, ported by a former colleague from an old Word file!)
Technical platform from NFR's and LSA having Data as core layer for consistency, Business Rules as another for scale and flexibility, Presentation as third for adaption to usage and technologies
Information models from what business works with not how, segmented into Domains with robust isolation interfaces using the Information Model, add application domains across and apply presentations as relevant
@hazelweakly I have a (untested) theory that communication and alignment are a key part of this.
If team A thinks the rigidity in the system is over here and team B thinks that part's flexible, but this other part is rigid, especially if they don't know they disagree, it's going to be bad.
@fidgetyhands@hazelweakly like with bone structure though, flexibility and robustness can be directional.
It is very possible for part A to see part B as inflexible, specifically from the former’s localized point of view and framing, which may be incomplete. In fact, B’s adaptability may be so fluent and effective that it is mostly unknowable to A.
I wonder, have we developed any techniques for identifying this? Or is it mostly something that we have to be comfortable never really knowing once a system gets to a certain size?
The sequence itself is uncertain but from an observation point need to be defined to create meaning for usage and insight to cause and impact
Segmentation into elements of basic constency (concepts, domains) can enable interactions (functions, processes, derivations ... ) to be accepted as chaotic events and responses
they mostly all agree on needing to continuously reevaluate situations, but to over-simplify, Leveson (STAMP) would aim for a better modelling tools to anticipate more, HRO theory would defer to expertise for localized decisions, others would look at goal conflicts and pressures as sources, Woods has a whole theory of graceful extensibility, etc.
Then there are other variations on how to look into it (ethnography, FRAM, NDM, etc.)
Using BOSH exclusively for deploying and operating software is a huge pain in a bunch of ways -- BOSH thinks it should entirely own the VPC its deployed in and has a bunch of expectations about how software should behave like e.g. it should have a drain script that always works so it can shut down nodes whenever it feels like it -- but if everything does that work it unlocks some magical operational capabilities.
@hazelweakly this makes me think of the difficulty of building stable systems on unstable foundations. Like if your language / framework / system APIs change too frequently you can never build anything long lasting on top of them
@hazelweakly do you think there's a sense in which some of the rigidity in a system is based on the values with which it is built? Yes you can build architectural 'hinge points' that allow for flexibility, but perhaps it's your values that determine where these hinge points are, and by extension, what other structures exist that you hinge around, which form the rigidity?
@hazelweakly Working through a version of this now at work, where our current stack is way too flexible, causing devs to carry far too much mental baggage around to do basic tasks. Things like inconsistent and confusing naming, surprising couplings, etc.
Maybe the incidental vs accidental complexity is a helpful frame? Rigidity should be provided at the places where its absence leads to pointless, unhelpful complexity. So for example insisting on meaningful names isn't being too rigid.
One thing that can be tricky IME about incidental vs accidental complexity is that both look the same in the present, and the past is really difficult to learn from when it comes to preventing the future.
What if everything is accidental complex? Do you throw it all out? If everything is incidentally complex, does that mean you can't improve it?
To that end, I've found it helpful to think about things by their existence rather than their origin
Add comment