Driven by Acronyms

Aspect-oriented programming, behavior-driven development, CAP theorem… can we cook some more IT alphabet soup? This method and practice reference (as is, to be) and TLA resolver is not to be taken (too) seriously.¹

Background

Story 22 on “Diagram-Driven Design” in Gregor Hohpe’s “The Software Architect Elevator” reminded me that I was actually one of the pundits who contributed to an “A-Z list of 26 new development strategies” once upon a time.

I can’t find my original notes (pre-smartphone days!); so this post is an attempt to recreate and update the collection of future practices, but also to remind us of actually existing ones.

What is on the menu already?

Are you “Driven”?

The following “driven” methods and styles exist:²

• Attribute-Driven Design (ADD) puts quality attributes first; Version 3.0 also covers architectural decisions about frameworks and technologies.
• Behavior-Driven Development (BDD) complements user stories with exemplary scenarios, acceptance criteria and test cases to encourage collaboration; it is supported by tools such as Cucumber and JBehave.
• Contract-Driven Design (CDD) combines Design by Contract with Test-Driven Development (see below), partially automating the creation of test cases.
• Domain-Driven Design (DDD), promotes modeling and a ubiquitous language shared by non-technical stakeholders and software people and provides patterns to structure the business logic of an application (as well as entire applications and service landscapes).
• Event-Driven Architecture (EDA) can be considered to decouple system parts that need to know about each other’s state changes, also allowing time-based analyses of business and system activities.
• Feature-Driven Development (FDD), takes a “client-valued feature perspective” and suggests five design and implementation activities (shouldn’t all methods and projects be driven by features?).
• Model-Driven Architecture (MDA) is a brand of The Open Group; Model-Driven Software Engineering (MDSE) is a related general term.
• Responsibility-Driven Design (RDD) was the first “driven” design method. And Readme Driven Development appeared in 2010.
• Specification-Driven Development combines Design by Contract (see CDD) with TDD for their mutual benefit (and also uses the term “plan-driven development” not featured separately here).
• Test-Driven Development (TDD) is not a test practice, but a “test first” (outside in) approach to coding that yields automated tests almost as a side effect.
• User-Centered Design uses a different participle, but could just as well be “driven”.

Note that these xDD practices stand on rather different levels of maturity and adoption, indicated to some extent only in the list above.

Maybe not “Driven” but “Oriented”?

Once upon a time it was enough to be “oriented” about a paradigm, method or style or (or “orientated” if you prefer British English):

• Aspect-Oriented Programming (AOP) separates cross-cutting concerns from the code core (5 Cs!): @ManyPropertiesCanBeInterwoven [AndAreProcessedAtCompileTimeAndRuntime]
• Interface-Oriented Design (IOD) is not a very well known TLA but there’s a book on it.
• Object-Oriented Analysis and Design (OOAD) and Object-Oriented Programming (OOP), co-locate data (variables) and logic (methods), emphasizing software engineering principles such as information hiding; certainly one key element in my professional toolbox.
• Message-Oriented Middleware (MOM), also known as messaging systems, support asynchronous, queue-based integration flows.
• There is a book series called Pattern-Oriented Software Architecture (POSA), focusing on distributed ones in particular.³
• You also find Resource-Oriented Architecture (ROA) and, focussing on Web clients, ROCA.
• I defined Service-Oriented Architecture (SOA) via principles and patterns in Chapter 2 of my PhD thesis (this definition is summarized and compared with definitions of microservices in this post).

I left out “-based” and “-centered/centric” and “-focussed” styles, methods and practices (with one exception, UCD). And still scored 18/26! I am sure there are more.

I am glad that reactive programming is not called reaction-driven or reactivity-oriented programming… and the pragmatic programmers are not pragmatism-centric either (rationale: avoid “zombie nouns”) 😉

From “Oriented” to “Driven” to “Something Completely Different”?

Will there be a next big theme in practice/method naming? It is difficult to make predictions, especially about future. George Fairbanks proposes to work in a “model-minded” way, but I haven’t come across any other “minded” methods yet (although I like the term).⁴ And “cloud-native” also seems to be a loner.

Finding good name is hard, as we can learn on Martin Fowler’s bliki and on MediaWiki (we can find some concrete advice there!), and we are looking for a meta name here. How about “enabled”, “friendly” or “inspired” practices and technologies? Time will tell.

Call for Method Meal Ingredients

Our practice alphabet soup is about 75% done already. So let’s find some more names still.

We can actually start from scratch and go from ‘A’ all the way to ‘Z’. While a few of the following suggestions actually exist, I make most ones up here:

• Activity-oriented development (which is mentioned in the Software Architect Elevator); runner up: artifact-centric processing (exists; for instance, consistency of business process models and object life cycles has been researched in depth)
• Balance-oriented design, emphasizing equal focus on short and long term design thinking; blockchain-oriented resource-, event- and document obfuscation method (BoREDOM), business-centered IT (or bonus-oriented development and operations?)
• Context-driven development (all methods should take their application context into account, as explained in this post), constraint-driven architecture (REST is one), cloud-native design and development
• Diagram-driven design is featured in Section 22 of Gregor’s Software Architect Elevator; deep software engineering (applying artificial intelligence and machine learning to software design and test; could not leave out this one!)
• Evidence-based software engineering has actually been proposed by researchers and practitioners (see here); ethical software engineering should be practiced too
• Framework-centric development, the counterpart of pure programming (see below); flow-driven design, function-oriented computing
• Guard-driven development, a parallel programming and concurrency management approach; gain-oriented design (an innovation technique evolving from Design Thinking)
• Hexagon-centric architecture exists as ports-and-adapters; hyperbolic engineering and hysteresis-aware development apply concepts from maths and physics to make sure that decisions are made at the most responsible moment and that the mid- and long-term consequences of design changes do not go under.
• Incident-driven development/evolution; integrity-oriented design
• Journal-driven development (an evolution and refinement of data analytics and event sourcing); just in time design (agile taken one step further)
• Knowledge-based software engineering; kernel-oriented programming, Kappa computing (predecessor or superset of Lambdas)
• Lambda-oriented software engineering or logic-oriented programming (existing under different names); License-Oriented Development (LOD) preferring products over projects
• Mindful software engineering; metadata-driven development
• Nanoservice design (such services are even smaller than microservices); Not-Driven-Development (NDD) so that even method agnostics can’t escape TLA hell 😉
• Ontology-driven design; organic computing
• Pure programming (no dependencies, DIY taken to the extreme); polyglot programming (heavy use of cross compilers)
• Quality-driven development; quantum-ready transactional software container hypervisor (QuaTSCH)
• Refactoring-based design (the method that supports the evolutionary architecture style); recursion-oriented programming
• Stakeholder-driven design or stream-oriented programming (can’t decide for a favorite here); state-centric development (a synonym for artifact-centric processing)
• Tradeoff-oriented decision making; transaction-oriented design, trend-agnostic software development
• Ubiquitous computing (from edge and fog to the backend, IoT) or ultimate programming (next generation XP)
• Value-driven design (all designs should be, but FDD made it too); variability-driven design and development (next generation Software Product Line Engineering, SPLE)
• Whiteboard-oriented design and service thinking suite is already there, but called agile modeling; the long name yields “WoDS-This” as a rather pithy acronym; workload-aware design (also problematic as TLA: WAD?)
• XDD, a fusion/crossover method combining at least three other whatever-DD methods; xeno-aware design (acknowledging that some external stakeholders might not be known or might be sceptic about project/program/product goals)
• YDD: Y-statement driven design (focussing on decision making rather than component structures)
• Zero-defect development (ZDD) was mentioned in the Software Architect Elevator… and Zengineering would be nice to have to.

Actually, some of these methods would be worth creating imho!

Pithy Acronyms

It is time to go back to the real world. Here are existing TLAs¹ (or nLAs) that stick because they pronounce well:⁵

As the co-cook of this alphabet soup Mirko Stocker pointed out, there are many numeronyms such as i18n, k8s, l10n and m17n. Strictly speaking, these are not TLAs (or nLAs), but rather Two-Letters-With-A-Number-Sandwiched-In-Between. 😉

What about fresh nLAs? I’ll save my creativity for the next research proposal. Wait… how about an acronym for the following quality criteria for methods and acronyms. We need:

Self-explanatory, Tradeoff Unveiling, Pragmatic, Intuitive Definitions.

Well, maybe not.

TL;DR

What can we take away from this post?

• IT and software engineering are TLA-heavy (or acronym-driven).
• More than 75% of the alphabet starts the name of a method, practice or development style in software engineering. The rest of the name space is pre-populated;¹⁰ feel free to pick one of the more serious “x-driven” or “y-oriented” proposals in this post (or start a new naming trend).
• One can find a pithy acronym for almost all letter combinations. When creating acronyms that are easy to pronounce and remember, make sure that they actually mean something that makes sense.
• If you want your research concepts or method elements to be remembered, give them names and acronyms that stick and, hopefully, do not cause undesired associations.¹¹
• Sometimes (meta-)method work can be fun, at least for some of us that are into such exercises; I commented on methods and their value more seriously here.

Did I miss an x-driven method or pithy nLA? Have you created one of the suggestions in this post? Nominations are welcome!

– Olaf (a.k.a. ZIO, socadk, MAP author), with help from Mirko Stocker