A lot of it is also just boilerplate, if by software we mean code...
I've often heard coders talk about "logic" as a vaguely intimidating mass noun, as in "ugh, this module is full of old logic, who knows what's going on here?"
The word "logic" normally implies structure, coherence, and correctness. In coding, that's rarely the case. We still need to learn how to code logically.
According to the article's terms I think boilerplate can be referred to as "trivial decisions", e.g. "there's no elevator in this building so I gotta trudge up the stairs" - there's no real decision there besides "do" or "don't" and a bunch of boring work you have to do in order to reach your goal.
I'm thinking also of stuff like complex hierarchies of "object orientation" that don't embody any actual logic, but only serve to impose a "structure" that may or may not have benefits.
Writing code that consists mostly of actual relevant decisions seems like an often-ignored art.
Comments
A lot of it is also just boilerplate, if by software we mean code...
I've often heard coders talk about "logic" as a vaguely intimidating mass noun, as in "ugh, this module is full of old logic, who knows what's going on here?"
The word "logic" normally implies structure, coherence, and correctness. In coding, that's rarely the case. We still need to learn how to code logically.
According to the article's terms I think boilerplate can be referred to as "trivial decisions", e.g. "there's no elevator in this building so I gotta trudge up the stairs" - there's no real decision there besides "do" or "don't" and a bunch of boring work you have to do in order to reach your goal.
I'm thinking also of stuff like complex hierarchies of "object orientation" that don't embody any actual logic, but only serve to impose a "structure" that may or may not have benefits.
Writing code that consists mostly of actual relevant decisions seems like an often-ignored art.