I find a program much more valuable when I can read it and understand the abstractions that collectively explain a theory of the problem and solution. In contrast, I find programs with minimal abstractions and lots of conditional logic hard to understand because there is little or no theory to be inferred. The object-oriented programming community has long sought correspondence between models of the domain and the classes in a program, but other communities strive for this too.
But the theory goes beyond just domain models, as solution models (design patterns, architecture patterns) and “critical thinking models” (eg design by contract and the functional thinking embodied in Z and VDM) are equally important.
For several years I’ve been trying to relate the many models that I build on software projects and I believe it’s a combination of models of the domain, the solution, and these critical thinking models. This leads to the question of what value a programming team is contributing, especially when “repeated delivery of stakeholder value” is the primary metric used today.
I argue that:
(1) programs that embody the theories of their developers are more valuable,
(2) how well developers can evolve a program is related to their ability to build and evolve theories, and
(3) a key distinguishing characteristic of a company’s most senior developers are their theory-building traits.
Delivered at WICSA/CompArch 2016
And here are the slides:
subscribe via RSS