… has been a major theme in my career for over 40 years.

In the early years, during the mid-1970s to late 1980s, this was largely about learning the ropes, programming in COBOL and various assemblers. Even though my first 10 years I was programming with COBOL, still the process was largely the same: using natural names in English where possible to communicate symbolically ideas about what the code intended to do. While linguistic metaphors were less in evidence, still there were at least hints about this. During the early 1980s, I began to think about how to represent ideas more in terms of objects and object-oriented designs, even though COBOL was not at the time especially well suited to this.

Then in 1990, I made the leap into full object-oriented programming and design with Smalltalk at Citigroup. While there for almost 9 years, I worked on many projects with many teams, eventually teaching object-oriented design and serving as a mentor for others. As a foundation for later work, I explored the linguistic elements of English as a natural language. I got to discover a bit more, and with more actual practice, how naming conventions and linguistic metaphors could be applied to software designs and code, especially with object-oriented programming and design.

I also learned more about how software requirements worked, and I could see more directly from where and how the ideas came into being in the minds and words of various stakeholders. I became fascinated by how problems could be described formally, and how important it was to distinguish and separate problems (in the world), their descriptions (formalized), and the resulting solutions (those ideas in code). All of this culminated in the writing of my first published article: Using Natural Language in Software Development. Thereafter followed a series of papers about conceptual modeling.

Making Ideas Sharable and Comparable

Since the early 2000s, I explored and elaborated on these ideas with the EDUCE process, developed a conceptual model for software requirements, and wrote about software metaphors, many of which underlie software development in practice. Much of EDUCE is about this: making ideas sharable and comparable, and then making those ideas shared in actuality by working teams, fostering commonality and an ubiquitous language.

There are still significant challenges associated with these efforts, though there have also been important successes and acknowledgement of its importance in practice. I was intrigued to find many of the ideas to which Eric Evans gave voice in his work on domain-driven design paralleled and complemented my own.