Right on. Another way to put it: if you have to spend extra effort on maintainability, you’ve probably screwed up somewhere.
My name for this kind of behavior is “fetish”. For example, some people have a Law of Demeter fetish. Some people have a short function fetish. And so on, all kinds of little cargo cults around.
Allow me to illustrate with another example. One of my recent projects is mostly composed of small functions, but there’s this one function that is three screens long. What does it do? It draws a pie chart with legend. The only pie chart in the whole application. There’s absolutely no use refactoring it because it’s all unique code that doesn’t repeat and isn’t used anywhere else in the app. Pick the colors, draw the slices, draw the legend, stop. All very clear and straightforward, very easy to read and modify. A fetishist would probably throw a fit and start factoring it into small chunks, giving them descriptive names, maybe making it a “class” with some bullshit “parameters” that actually only ever take one value, etc, etc.
Well, that’s merely labeling, not actually advancing an argument. What kind of predictions are we talking about here? Where is our substantial disagreement, if any?
When I talk about maintainability I’m referring to specific sequences of events. In one of the most common negative scenarios, I’m asked to make one change to the functionality of a program, and I find that it requires me to make many coordinated edits in distinct source chunks (files, classes, functions, whatever). This is called “coupling” and is a quantifiable property of a program relative to some functional change specification.
“Maintainable” relative to that change means (among other things) low coupling. You want to change the pie chart to use dotted lines instead of solid inside the pie, and you find that this requires a change in only one code location—that’s low coupling.
Now what often happens is that someone needs a program that’s able to do both dotted-line pies and solid-line pies. And many times the “most natural” thing (by which I only mean, “what I see many programmers do”) is then to copy the pie-chart function, paste it elsewhere with a different name, and change the line style from solid to dotted.
That copy-paste programming “move” has introduced coupling, in the sense that if you want to make a change that affects all pie charts (dotted and solid alike) you’ll have to make the corresponding source change twice.
Someone who programs that way is eventually going to drive coupling through the roof (by repeated applications of this maneuver). At this point the program has become so difficult to change that it has to be rewritten from scratch. Plus, high coupling is also correlated with higher incidence of defects.
Now you may call a “fetishist” someone whose coding style discourages copy-paste programming, that doesn’t change the fact that it is a style which results in lower overall costs for the same total quantity of “delta functionality” integrated over the life of the program.
My contention is that functions which are three screens long are, other things equal, more likely to result in copy-paste parametrizations than smaller functions. (More generally, code that exhibits a higher degree of composability is less susceptible to design mistakes of this kind, at the cost of being slightly harder to understand for a novice programmer.)
I’d probably look hard at this pie chart thingy and consider chopping it up, if I felt the risk mitigation was worth the effort. Or I might agree with you and decide to leave it alone. I would consider it stupid to have a “corporate policy” or a “project rule” or even a “personal preference” of keeping all functions under a screenful. That wouldn’t work, because more forces are in play than just function length.
Rather, I assess all the code I write against the criterion of “a small functional change is going to result in a small code change”, and improve the structure as needed. I have a largish bag of tricks for doing that, in several languages and programming paradigms, and I’m always on the lookout for more tricks to pick up.
What, specifically, do you disagree with in the above?
I agree with most of your comment, except the idea that you can anticipate in what directions your software is going to grow. That’s never actually worked for me. Whenever I tried designing for future requirements instead of current simplicity, clients found a way to throw me a curveball that made me go “oops, this new request screws up my whole design!”
If my program ever needs a second pie chart, it’s better to factor the functionality out then instead of now. Less guesswork, plus a three-screen-long function is way easier to factor than a set of small chunks is to refactor.
except the idea that you can anticipate in what directions your software is going to grow
It’s ironic that I should be suspected of claiming that. Let me reassure that you on this point, we agree as well. (It’s looking more and more as if we have no substantial disagreement.)
My point is that the risk is perhaps lowest if you are going to add the second pie chart, but if someone else is, the three-screens-long function could be riskier than a slightly more factored version. Or not: there is no general rule involving only length.
If you want to make a pastie with that function I could give you an actual opinion. ;)
I wasn’t with you on the importance of maintainability until you said this. Yes, programming well and naturally is automatically maintainable.
Right on. Another way to put it: if you have to spend extra effort on maintainability, you’ve probably screwed up somewhere.
My name for this kind of behavior is “fetish”. For example, some people have a Law of Demeter fetish. Some people have a short function fetish. And so on, all kinds of little cargo cults around.
Allow me to illustrate with another example. One of my recent projects is mostly composed of small functions, but there’s this one function that is three screens long. What does it do? It draws a pie chart with legend. The only pie chart in the whole application. There’s absolutely no use refactoring it because it’s all unique code that doesn’t repeat and isn’t used anywhere else in the app. Pick the colors, draw the slices, draw the legend, stop. All very clear and straightforward, very easy to read and modify. A fetishist would probably throw a fit and start factoring it into small chunks, giving them descriptive names, maybe making it a “class” with some bullshit “parameters” that actually only ever take one value, etc, etc.
Well, that’s merely labeling, not actually advancing an argument. What kind of predictions are we talking about here? Where is our substantial disagreement, if any?
When I talk about maintainability I’m referring to specific sequences of events. In one of the most common negative scenarios, I’m asked to make one change to the functionality of a program, and I find that it requires me to make many coordinated edits in distinct source chunks (files, classes, functions, whatever). This is called “coupling” and is a quantifiable property of a program relative to some functional change specification.
“Maintainable” relative to that change means (among other things) low coupling. You want to change the pie chart to use dotted lines instead of solid inside the pie, and you find that this requires a change in only one code location—that’s low coupling.
Now what often happens is that someone needs a program that’s able to do both dotted-line pies and solid-line pies. And many times the “most natural” thing (by which I only mean, “what I see many programmers do”) is then to copy the pie-chart function, paste it elsewhere with a different name, and change the line style from solid to dotted.
That copy-paste programming “move” has introduced coupling, in the sense that if you want to make a change that affects all pie charts (dotted and solid alike) you’ll have to make the corresponding source change twice.
Someone who programs that way is eventually going to drive coupling through the roof (by repeated applications of this maneuver). At this point the program has become so difficult to change that it has to be rewritten from scratch. Plus, high coupling is also correlated with higher incidence of defects.
Now you may call a “fetishist” someone whose coding style discourages copy-paste programming, that doesn’t change the fact that it is a style which results in lower overall costs for the same total quantity of “delta functionality” integrated over the life of the program.
My contention is that functions which are three screens long are, other things equal, more likely to result in copy-paste parametrizations than smaller functions. (More generally, code that exhibits a higher degree of composability is less susceptible to design mistakes of this kind, at the cost of being slightly harder to understand for a novice programmer.)
I’d probably look hard at this pie chart thingy and consider chopping it up, if I felt the risk mitigation was worth the effort. Or I might agree with you and decide to leave it alone. I would consider it stupid to have a “corporate policy” or a “project rule” or even a “personal preference” of keeping all functions under a screenful. That wouldn’t work, because more forces are in play than just function length.
Rather, I assess all the code I write against the criterion of “a small functional change is going to result in a small code change”, and improve the structure as needed. I have a largish bag of tricks for doing that, in several languages and programming paradigms, and I’m always on the lookout for more tricks to pick up.
What, specifically, do you disagree with in the above?
I agree with most of your comment, except the idea that you can anticipate in what directions your software is going to grow. That’s never actually worked for me. Whenever I tried designing for future requirements instead of current simplicity, clients found a way to throw me a curveball that made me go “oops, this new request screws up my whole design!”
If my program ever needs a second pie chart, it’s better to factor the functionality out then instead of now. Less guesswork, plus a three-screen-long function is way easier to factor than a set of small chunks is to refactor.
It’s ironic that I should be suspected of claiming that. Let me reassure that you on this point, we agree as well. (It’s looking more and more as if we have no substantial disagreement.)
My point is that the risk is perhaps lowest if you are going to add the second pie chart, but if someone else is, the three-screens-long function could be riskier than a slightly more factored version. Or not: there is no general rule involving only length.
If you want to make a pastie with that function I could give you an actual opinion. ;)
Object-oriented design is overrated. ;)