Most all automations are not defined by the standard case or the typical inputs but by exceptions. – Steven Sinofsky

In some ways, programming is all about automation. BUT there are some tasks that are more clearly about it than others. While reading about the philosophy of various build/data-pipeline systems, I came across this post about what drives complexity in such systems. It’s not the “happy path”, its the “sad path”…because there are usually so many sad paths and so many ways to get onto them!

A second point the article drives home is that the exception/error cases are usually discovered incrementally through use. They almost by definition can’t be built in from the start because they often don’t even exist when the system is first created.

Having recently helped my daughter get her driver’s license, the point about many human-centered processes being focused on exceptions really drove home. I have renewed my licence many times through the years. I use a mail in form (anciently) or electronic form (recently). But a FIRST license is an exception case…and required a trip the BMV and standing in line…and going back three times for various bureaucratic (i.e., exceptional case) reasons.

The observation at the end of the article is that many successful computer tools help people to finish a job rather than start a job. The folks I know who are powerpoint/illustrator/chatGPT are capable, knew their inputs, are well versed in the non-computer skills relevant to presenting/graph-design/writing. They could do it themselves, but computation/automation helps them do it faster. The people that don’t have those baseline skills….no amount of powerpoint wizardry, illustrator fiddling or ChatGPT prompting will save their presentation/drawing/novel.