The distinction between writing code and writing prose is not as great as some might imagine. I recently read an article that compared novelists’ metaphors concerning writing. The distinctions included the “architect” who meticulously plans out the structure of the novel. Plots, characters, sets, chapter structure—everything—are diagrammed and refined prior to beginning writing. All that remains is word choice, dialogue, and the gritty details of putting it all on a page. Compare this to the “farmer” approach where a seed is planted in the form of a key idea or plot development. The writer begins with that seed and nurtures it in a continuous process of development. When the tree grows lopsided, there is pruning. When a branch withers, there is watering and attention. The balanced whole builds organically and the architecture is an emergent property.
Coding is similar. We generally know the architecture in advance, though there are exceptions in the green fields. Full stack development involves decoupled database back ends, front end load balancers and servers, and middleware/coding of some stripe. Machine learning involves data acquisition, cleaning, training, and evaluation. User experience components then rely on “patterns” or mini-architectures like Model-View-Controller and similar ideas pop up in the depths of the model and controller, like “factory” patterns that produce objects, or flyweights, adaptors, iterators, and so forth. In the modern world of agile methodologies, the day-to-day development of code is driven by “stories” that are short descriptions of the goals and outcomes of the coding, drawing back to the analogy with prose development. The patterns are little different from choosing to use dialogue or epistolary approaches to convey parts of a tale.
I do all of the above when it comes to writing code or novels. For my recent projects that are in development simultaneously (I need several because I suffer from enthusiasm gaps when I only have one going), I have been spending more time and effort on architecture. For Tusker Long, for instance, I have a plot spreadsheet that goes through the main arcs and sub-arcs of the plot lines, including the particular narrative form or voice that will be applied in each section. Since it is told from many perspectives, some reliable and others less so, and because world building is handled through non-narrative essays, games, and epic poetry, figuring out the pacing and relationships in advance is critical to continuity. Other development documents include character descriptions, chapter layouts, an onomasticon, bestiary, and gazetteer. Also, since I am moving away from traditional platforms of downloaded content or bound pages, there are brainstorming documents on other ways to move content components into new presentation modalities. I’ll leave that brief and abstract since I want to surprise the reader (engager?), but I will mention I recently experimented with block chain concepts. The future of the novel is as a form of cryptocurrency?
But for other novels it has been very organic, with just the barest of plot outlines and characters emerging from a general necessity of the conflict at hand. This has presented problems, the most important of which is a need to revise and revise to work new developments, foreshadowing, and people into the earlier novel. Cohesive and coherent are always at risk, and even then there is always the concern that it lacks polish in its architecture.
Coding that doesn’t work is easier to deal with. It just has to be rewritten until it works, but often old decisions that could be rewritten have to remain unretouched out of a basic prioritization that functionality is critical and getting to a minimal viable product is essential. The old code lingers as “cruft” and you have to apologize for it occasionally. With a larger team, reimplementing crufty portions of the codebase is a good gating task for junior programmers to get familiar with things, but it also introduces the potential for errors since the same developers are less familiar with the dependencies that are reliant on those components.
So we have cruft versus cohesion, though I have occasionally completely reworked chapters into another form purely to alleviate the repetitiveness of just more descriptive prose. So a kind of cruft makes its way into prose, too, in the form of a lack of flair or style. And, occasionally, just because it could be done better.