Foreword

Meilir Page-Jones

People often ask me:

"Would you say that software development is more an art or a science?"

I reply,

"Neither. It's a branch of the fashion industry."

Every couple of years the software industry is gripped by one hot fad or another. We've had "structured stuff," "relational stuff," "agile stuff," "RAD stuff," "Kanban stuff," "DevOps stuff," "cloud stuff," and so on. Each fad attracts its fanatical adherents, as well as its outraged opponents. Then, after a few years of heated passion, the fires die down on that particular fad. It becomes "old hat" and the fad's remaining adherents are called dinosaurs. (How's that for a mixed metaphor?) Then it's time to move on to the next craze.

I'm not saying that these fads are bad or useless. Most are effective in the right contexts. The problem is sociological. Software can never become a true engineering discipline if techniques are hailed as game changing at one time and decried as antiquated the next-for no reason other than that the fashion changed.

So it is with modeling. For the most part, software modeling arrived during the 1970s. It included (loosely speaking) approaches such as data flow diagrams, control flow diagrams, entity-relationship diagrams, state-transition diagrams, and code-structure diagrams. These diagrams were made more robust by standardized textual definitions of their components. Some were aimed at the elicitation of software requirements, and others more at the sound construction of code.

This was a healthy trend for a field that was supposedly seeking to become an engineering discipline. After all, other engineering disciplines (such as civil, mechanical, industrial, and electrical engineering) depend on diagrams of components with their relationships and specifications.

When software modeling arrived, three things happened. The first was that people found it intellectually more difficult than the code-and-fix approach. The second (stemming from the first) was that many people gave up before they mastered it. The third was that-in shops that persevered with modeling-software productivity, quality, and manageability all increased markedly-in other words, a mixed landscape where some made great advances through modeling . and unfortunately others did not.

It didn't help that in the 1970s software modeling was an experimental craft, which only a few dedicated early adopters could take to its full potential. It was immature and lacked solid standards and support tools. But the situation gradually improved so that by the mid-1980s software modeling was mature enough to be called mainstream.

Well, sort of. There was indeed a deeper understanding of modeling techniques, more conferences and seminars about it, further standardization, and some tool support. But there were still enough gaps to keep modeling from being universal in the software industry. Nevertheless, I naively thought that the progress would continue: modeling would remain mainstream and become more widely adopted, more sophisticated, and better supported by automated tools. The trend was certainly in that direction.

But I'd reckoned without the Forces of Fashion. By the 1990s, and definitely into the 2000s, software modeling had been dubbed "antiquated and only for the Triassic reptiles of the 1980s." More than once I heard comments such as:

"That modeling crap is just for structured stuff. We're an object-oriented shop."

It was into this world of the 1990s that the Unified Modeling Language (UML) entered. UML synthesized some of the modeling approaches of the 1970s and 1980s, along with object-oriented constructs and a couple of techniques from electrical engineering. UML both standardized modeling notation and embraced object-oriented concepts. Though not perfect, UML was a major step forward and also ushered in a new generation of robust and sophisticated modeling tools.

It was ironic timing. The fashion pendulum was already swinging against modeling. In the 2000s the agile movement pushed the pendulum further against modeling by-perhaps deliberately, perhaps inadvertently-decrying documentation, which apparently included models. (I have more to say about that below.)

Currently, we're in the bizarre situation where, in what should be a golden age for software modeling with stable notation and mature tools, fewer software engineers by proportion are practicing modeling than in the 1980s. Software modeling is in danger of becoming lost knowledge.

The previous paragraph makes a mockery of the term "software engineering." Do you know any serious branch of real engineering that does not use rigorous "talking" models of whatever they plan to build? ("Talking model" is my term for a predictive model-one that can answer within acceptable tolerance qualitative or quantitative questions about the subject to be built and maintained. For example, "What overall load and local pressure can this new bridge support?")

At this point, enters Steve Tockey. Because software modeling is probably now at its most retrograde phase, it's poised to swing back into favor. So Steve's book on software engineering comes at just the right time to give modeling a hefty shove in the right direction.

Steve, whom I've known for over 30 years, is also just the right person to write this book. He's an adept programmer and a remarkable teacher. More germanely, he's about the best modeler of the business world and of software systems that I know. And, to top it all, he's a fan of Bert Weedon.1

This book represents the confluence of all Steve's talents. He brings to bear his teaching ability, as well as his vast experience on all kinds of systems: large and small, embedded and business, noncritical and safety-critical. Some of that experience was as a programmer. Some was as an analyst. Most of it was as a modeler.

I have voluntarily and happily flown in planes whose test software was developed from models that Steve produced. I can't think of anyone better placed than Steve to write a comprehensive book on software modeling.

But why should you bother to read this book? Didn't I just say that software modeling is out of fashion? Maybe so, but from your perspective, that's not the point. If you're a true engineer, fashion doesn't matter. When I first learned modeling as a developer, the quality and quantity of my code took an immediate jump for the better. That's a very typical experience, by the way. I adopted this motto:

"I'm a software engineer. I don't need anyone else's permission to do modeling. I don't even care whether it's fashionable or not. It works."

This is even more true today: half a day's salary can buy you your own state-of-the-art (not a toy) software modeling tool. You really don't need anyone else's permission. So I expect that software modeling will swing back into fashion before long. Quietly, some of the top companies are already doing it-for several good reasons.

Modeling promotes better communication among teams well before code is written. After the code has been written is a bit late! Software modeling also embodies true engineering tenets. You'll find a lot of them in this book, but let me just call out one in particular, which is probably the best-kept secret in software engineering: domain separation (Chapter 6). Here's an illustration of what it means.

On the desk in front of me is a lamp with domain separation. Without that separation, in order to change the bulb, I'd need to unsolder the wires from the old bulb and resolder them on to the new bulb. But the domain of transporting electricity to my desk (including wires) is cleanly separated from the domain that turns electricity into light (the bulb). The screw-in socket is the well-defined bridge between the two domains.

That's just a small illustration; Steve will take you more deeply into how it applies to software. Without domain separation in software, code gets "soldered together" in ugly ways that degrade portability, optimization, debugging, and even team organization. In fact, modeling itself becomes difficult.

OK, domain separation is not very useful for tiny systems. But it's vital for the medium and large systems that most of us encounter now in commerce, industry, science, and the military. I know of several large-system efforts that produced unmaintainable code or collapsed altogether because they'd failed to appreciate domain separation.

I won't take any more space in this foreword to promote arguments for modeling-or the arguments against not modeling-because Steve himself makes those arguments so well in this book. But I'd better mention the "A" word again or you'll think I'm not agile enough for prime time. (You think I'm not Agile? Oh, the shame of it!)

A powerful myth has arisen that if you do any modeling at all then you're not agile. But it is just a myth. In fact, modeling is highly compatible with Agile. I've been on four significant agile projects. One was very successful, two turned out reasonably well, and...