JON'S MUSINGS

Transmutation of Reality

I recently became involved in an interesting exchange of opinions with Mark Seemann (and others) regarding No Silver Bullet – Essence and Accident in Software Engineering, a famous essay by Fred Brooks first published in 1986. I forced my way into the debate after I listened to a .NET Rocks episode that had Mark as its guest, and in which he questioned at least some aspects of the essay’s central tenet and its continued relevance. I later read his article, Yes Silver Bullet, where he elaborates on his ideas. (It predates the podcast.)

As I felt Mark (as well as Carl and Richard, the podcast hosts) had possibly missed some critical points, I wrote Full Silver Jacket as my response. The discussion didn’t end there: Mark kept it alive by writing Modelling versus shaping reality. In addition, we exchanged several comments 😊

In the latest installment to date, Mark steers the conversation to questions about the purpose of software and its relationship with the broader world. Specifically, he ponders whether software products should merely “model reality” and concludes that they should generally be a lot more ambitious: They should aim to actively alter it – shape it.

I agree with Mark (almost) 100%. Unlike him, however, I don’t think his arguments go against those expressed in No Silver bullet. In my opinion, they’re complementary, and I believe I can provide “scientific” evidence to support my claim 😊

Blasts from the past

As I mention in my comment on the post, Mark’s reasoning (strangely enough) reminded me of the fact that I have a (bachelor’s) degree and, at one point in my life, wrote a “thesis” (or something like that). And, interestingly, an idea closely related to Mark’s was one of the thesis’ central themes.

I’m going to make an admission here: I didn’t start my “research” with a question or a hypothesis the way you should. Instead, I wanted to make a point; I wanted to argue that software interacts with its environment in ways that go way beyond modeling, automating, or simulating the world.

Paraphrasing various sources, I asserted that “few practical … systems are mere computer representations or simulations of the real world.” As examples of concepts introduced by software, I cited (electronic) spreadsheets, word processor documents, and virtual chat rooms. Speaking about technology in more general terms, I also mentioned automated teller machines (ATMs).

My plan was to present a project I’d worked on for a client as a case study. (I had been active in commercial software development by then.) However, to support my claims, I needed a conceptual framework.

And, lo and behold, I found a then brand-new article that provided me with just that 😊

Three-dimensional modeling

On the difference between analysis and design, and why it is relevant for the interpretation of models in Model Driven Engineering is an academic paper. I found it very interesting (and it pertained to my thesis), but to a practical software developer, it can feel very long and a bit heavy. Fortunately, I’ve read it, and I believe I can explain the gist with relative ease 😊

The authors asked a seemingly straightforward question: What exactly is the difference between analysis and design in software development?

Perhaps (un)surprisingly, they didn’t find a definitive answer. However, based on a review of various sources, they identify three different perspectives – three ways to approach this; three sets of criteria people have used:

• Purpose – description/specification
  • Analysis models describe (an existing thing)
  • Design models specify (something to be built)
• Reality – domain/system
  • Analysis models are models of the problem domain
  • Design models are models of the software system/product
• Abstraction – abstract/concrete
  • Analysis models are abstract/high-level
  • Design models are concrete/detailed

Purpose is in line with the dictionary definitions of analysis and synthesis (i.e., design). Reality corresponds to the traditional understanding of the distinction in object-oriented analysis and design. Abstraction tells you how detailed a model is (high-level – analysis/low-level – design).

The individual perspectives are, at least to a degree, independent; each may give you a different answer. As you apply them as your “prisms,” the same development activity may thus appear as both analysis and design. You can, for instance, perform a high-level (abstraction – analysis) specification (purpose – design) of the domain (reality – analysis).

Note: In today’s world, where everyone practices agile software development, the terms analysis and design reek of the waterfall model, and people tend to avoid them. I’m 100% behind iterative development. Still, I think that, as concepts, they apply even to work delivered in very small increments. Besides, I find it intriguing that while analysis and design aren’t cool anymore, business analysts still exist (and don’t seem to be an endangered species), and so do software architects (designers by definition).

Example

Imagine you live in a world where no spreadsheet software exists, and you’re building it from scratch. You will hopefully start by analyzing the users’ problems, but let’s assume you later have an epiphany and envision a conceptual spreadsheet as a solution. And, before you start worrying about the “how” (hardware, runtime environment, software architecture, etc.), you write up an implementation-agnostic specification of your new invention.

The $64k question: What you just did – is it analysis or design?

The $64k answer: It depends!

Let’s examine it in terms of the individual perspectives.

Purpose: It’s design – you designed a concept that didn’t previously exist.

Reality: It’s analysis – your spreadsheet, at this stage, is theoretical; you’ve done no technical/system design.

Abstraction: It’s both analysis and design – presumably, you started with a high-level model (analysis) and later moved on to the details (design).

Now, I understand this is an extremely idealized narrative. In reality, development can and should happen incrementally, with later stages building on feedback from earlier ones. But here’s the bottom line: Spreadsheets have become a fact of life. People give them names, talk about them, and it doesn’t matter if they use Microsoft Excel or Google Sheets to edit them. If you performed an object-oriented analysis of today’s world, you would discover the Spreadsheet as a class. Yet, they're so much more than a mere automation of the (paper) accounting worksheet, the concept that inspired their creators.

Software shaped reality by introducing spreadsheets into it.

Visualization

As the authors of the paper identified three perspectives (and not more), you can visualize development activities by plotting points on a chart (proposed by the authors) – each perspective becomes an axis:

Please note that points closer to the origin represent “analysis,” those further away “design.” The idea is to depict a development project (or a portion of it) as a “trajectory” through this three-dimensional space. This is what the authors believe such a trajectory might often/typically look like:

You start with an abstract description of the domain (A) and proceed to an abstract specification of the system (B) and, finally, a concrete specification of the system (C). This trajectory would accurately represent a “traditional” project where you analyze “reality” and then “model” it as a software system. (It’s the approach Mark and I both caution against 😊)

I won’t delve into the details, but here’s the trajectory I showed to describe the case study in my thesis:

It looks complicated – maybe I got carried away just a little bit – but this matters: Points C and D represent an abstract specification (C) and a concrete specification (D), respectively, of the domain.

What’s the point?

Let’s accept the ideas the authors express in the paper – at least for argument’s sake – and apply them to No Silver Bullet and Mark’s article. I think that Fred Brooks adopts the reality perspective. (He sees essence – the domain – and accident – the system.) Mark, on the other hand, observes things through the purpose prism. (He maintains that software should shape – i.e., specify – as opposed to model – i.e., describe – the world.) Yes, I know I’m oversimplifying, but I believe the concerns are orthogonal. (In the case of the chart shown above, literally so 😊)

That said, I sustain the (anticipated) objection that they’re not nearly as independent as their “perpendicularity” might suggest. You can’t just dream something up pie-in-the-sky, ivory-tower style; technology will both constrain and inform your choices. That, by the way, is what the dashed line between the C-to-D transition and the E-to-F transition in the figure above represents – the (two-way) interaction between domain design and system design.

In my previous post, I effectively concluded that software developers should spend more time familiarizing themselves with the problem domain and talking to their users and other stakeholders. Today, I’d like to add that it should go both ways: Domain experts and business decision-makers might benefit from treating software developers like serious partners (and not just geeky weirdos). They should approach us with problems they expect us to solve, not solutions they simply want implemented. If they do, perhaps they’ll be (pleasantly) surprised by what we can invent for them.

Note: On the difference between analysis and design, and why it is relevant for the interpretation of models in Model Driven Engineering, the paper discussed, was authored by Gonzalo Génova, María Cruz Valiente, and Mónica Marrero and published in the January 2009 issue of The Journal of Object Technology. (The full text is available free of charge.)