Vernacular Developers

A vernacular software developer creates software in a specific context, has principal responsibility in that context, and has professional training, if any, in that context rather than in software development. The alternative term “end user programmer” is pejorative; “non-professional” is misleading as many are professional, just at something else. pdf

Vernacular developers are typically not trained, nor interested in being trained, to use traditional general-purpose programming languages, nor do they necessarily share the cultural knowledge of the software domain or its engineering sensibilities about system integrity, maintenance, backup, and the like.

It is important to support programmers who are developing the software as a way of understanding their problems or the ramifications of their decisions. These people are using software to work toward a specification rather than from one.

The models and abstractions embedded in traditional programming languages are foreign to many vernacular software developers. These developers may become frustrated while trying to understand how to apply these foreign concepts to their own tasks. Conversely, the models of some non-language tools may be frustratingly foreign to professional developers.

Using AutoCAD successfully requires more than the ability to visualize 3D objects. Orchestrating the interaction with other parts of the ecosystem is also a programming activity, for example when converting the 3D model to a toolpath for a CNC machine tool or preparing it for 3D printing by adjusting for the properties of the intended material and providing auxiliary support structure.

A senior industrial developer with a PhD recently said, “Over several years, I’ve tried and failed to learn functional programming because that means learning a big pile of applied category theory. Despite claims that I can just use the parts I do understand, I find that reusing common libraries, like web serving, entails understanding the advanced stuff because it’s revealed in their interfaces.”

Real software components have incomplete, evolving, heterogeneous, and nonmonotonic descriptions; a propensity to change without notice; and undocumented assumptions. Their descriptions evolve as new information is gathered from usage or analysis.

The completeness of specifications is particularly problematic. First, the list of properties that might be specified is open-ended, and it’s hard to list them all, let alone to verify them. When observable properties are not specified, programmers may make tacit assumptions that run afoul of the actual implementation.

The criteria for “fitness for purpose”, whether the software is “good enough”, depend on things like the consequence of something going wrong and the likelihood that a problem will be detected and corrected before anything goes seriously wrong.

A programming error in a set of Python scripts commonly used for computational analysis of chemistry data returned varying results based on which operating system they were run on—throwing doubt on the results of more than 150 published chemistry studies.

The reason for the variation was the scripts’ use of Python’s glob module, which searches for files matching a specific name pattern—the scripts generated a list of input files to read based on the glob results. But the module depends on the operating system for the order in which the files are returned.`

Routine, or precedented, design is appropriate in well-understood settings where a body of engineering and domain knowledge supports finding solutions that are similar to established solutions.

Innovative, or unprecedented, design is appropriate when extensions to engineering and domain knowledge are required to find satisfactory solutions. This largely aligns with exploratory programming, especially when the design is exploring what’s actually possible.

Inkwell illustrates a contrast between two design paradigms. Designers work in two important modes: design as problem-solving and design as problem-setting.

Our myths celebrate design as problem-solving, of which Simon was a leading proponent. But there’s another side of design, of which Schön was the leading proponent where the designer begins with partial understanding of what’s actually needed and evolves that understanding by “conversation with the materials”.