Adaptive Design for Software - A Proposal

A Working Theory That Leverages Systems Thinking & Adaptive Management

Houston Haynes

7 minute read

TL;DR

Adaptive Design for Software [AD4S] started as a thought experiment - a moment of clarity from my 20+ years in software and leading teams - from start-ups to multi-national conglomerates. AD4S is a rubric for decisions in complex software that maintains a first-create-then-evaluate working pattern. It provides descriptive and prescriptive guidance for teams to evaluate for and avoid costly mistakes in user experience, performance, scale, accessibility, sustainability, security and proactively mitigates legal and regulatory risks. It also provides a declarative framework for anticipating potential unintended harms and related ethical considerations - particularly those ripple effects that constantly surface in “move fast and break things” culture.

The intent of AD4S is to establish the shared responsibilities among the various constituencies that build, maintain and use the software. Think of it as version management for higher-order product guidance. Through curation of an AD4S ledger a shared agreement is established between the company and its customers as well as other affected groups, and provides a guide rails to the engineering teams that support those systems they build and maintain.

Everyone in the working group has to recognize their responsibilities outside of the ‘super power’ that brought them to their role. In Adaptive Design for Software this precept is as foundational as the law of gravity.

AD4S aspires to make measurable the true cost and actual consequences of product decisions. In order to make it useful to as many organizations as possible it is conceived as a community-led project, which will pose many challenges and opportunities. For that purpose a handful of useful TLDs have been reserved. [adaptivedesign.software, ad4s.org, ad4s.net, etc.] The next step is to establish the proper location for contributions to be collected and receive comments from the broader community. The result will be a clearinghouse of information where concepts and course-corrections can be mapped out. The hope and expectation is that organizations and individual contributors of good faith will help cultivate AD4S precepts and help build an actionable, responsive and responsibility-minded compendium for crafting better software.

What follows is a series of notes, sketches and ideas that outline the problem space, along with a few ideas around how to shape a potential solution. This isn’t an attempt to create the entire AD4S site on my blog - but more of my own “sketchbook” of examples that underscore the need for AD4S to exist - and hopefully inspire some constructive dialog along the way. Readers should expect to see additional entries and more than a few edits in the coming days and weeks.

On the corrosive nature of performative leadership

One crucial factor that should be stated up front is that this is not another rubber stamp acronym program. Yes, there’s an acronym. But that’s as far as it goes. If you’re scouting for more flare to put on your suspenders to wear to work - look elsewhere. My experience is peppered with similar experiences where someone plants their flag in front of the parade with, “I’m here to represent the business” - and in AD4S that posture is a cardinal anti-pattern. This is most often brandished in project management as a means to confer authority - but can surface within a variety of roles across the working group for any number of reasons. To be fair this can be a constructive comment, but history betrays this to be more akin to explaining a joke - if you have to explain it, it’s not as impactful as you might think. While it’s more common for this type of troubling language to be passed around in corporate IT (where software is a cost center for the business, as opposed to being a driver of profit and loss) it has leaked into prima facae software shops as well. It implies that the business-to-software-engineering dynamic can be proxied by any generalist. And as with many systemic problems it’s often a signal of a broader issue within the organization.

It’s a dire warning signal when an IT project is primarily cast as a procurement exercise. This particularly applies to “digital transformation” where previous procurement-centered systems have left an ocean of technical debt in their wake. You can’t spend your way past missing technical or domain expertise - and the longer it has been absent, the more expensive it is to restore. While it’s more obvious than ever in today’s technology landscape, it has always been that way.

Any manager that reflexively “buffers” themselves from the responsibility of active systems management is likely missing key elements in their background and experience to realize that this approach works against business needs. This is what “performative leadership” refers to - and it has myriad forms in any size organization. It’s both a process and institutional “smell” for this attitude to persist. At its worst it’s a double abdication. On one hand, engineers may be “let off the hook” to disconnect from business input due to proxies that don’t have actual domain knowledge. And similarly it can also be a means for the non-adept business leaders to parachute non-technical staff into the project. While it has any number of excuses, it too often is also used to shield the responsible business party from exposing their inability or unwillingness, to provide actionable domain knowledge.

Three common mistakes to avoid.

These kinds of institutional disconnects - whether by accident, cultural reflex or by design are the beginning of the end for any software project and is often an unseen strategic liability for the company. The common practice of “body-ing up” the room with a cadre of eager-but-inexperienced contributors only serves to further undermine a project’s charter and dims prospects for a timely, successful delivery.

Good design and proper engineering is everyone’s business

Everyone in the working group represents the business. Everyone in engineering has some responsibility to comprehend the broader aims of the system they’re building. This concept is about the necessity of a “Venn overlap” across the working group and everyone being fully engaged in expressing the targeted domain. Simply eye-balling a calendar won’t cut it. Along those lines, it’s the role of every business person and their proxies to carry enough comprehension of business domain to cultivate an ongoing constructive dialog with technical resources. Walking around with a Gantt Chart and a clipboard will not suffice. This means “meeting the engineers where they are” and having a working understanding of the technical solution such to support their side of a meaningful discussion that can propagate a virtuous feedback cycle. Engineers also must have a working mental model of the current state and future state of the business process under purview - a shared “tribal knowledge” construct that fosters rapid solution development and minimal course corrections. This is about more than competency, it’s about empathy. There are no exceptions to this. There are no “escape hatches” - such as excusing business-facing internal software solutions as separate from customer-facing end-user applications. Regardless of whether the software is licensed or built in-house, everyone in the working group must recognize their responsibilities outside of the ‘super power’ that brought them to their role. In Adaptive Design for Software this precept is as foundational as the law of gravity. Without it, things simply fly apart.

What’s in a name?

So the first footnote to this series of posts is to answer the question “why AD4S?” Of course I wanted a moniker that was brief and catchy, but I also thought it was equally important for the long form to convey specific intent. First and foremost, this process is about adaptation, and recognize the constant tension on complex solutions well beyond technical concerns - even on a relatively mature platform with a low internal change rate. This framework is about expressing design intent as an ongoing initiative that’s equal to and sometimes supersedes elements of technical concerns. Yes, user demands and Moore’s Law are most definitely two pivotal factors. But there are an array of issues and considerations that are their equal - and AD4S attempts to embrace and reconcile each of them in a way that’s responsible to its customers, producers and where applicable also to broader constituencies that may be indirectly impacted by those decisions.

Key Value
BuildDateTime 2021-06-15 16:21:40 -0700
LastGitUpdate 2021-06-12 10:59:02 -0700
GitHash ec878bd
CommitComment Using F# function for site cards