Originally posted July 2019. This is a topic I’ll revisit in book 2, since teams will need to synchronize on what they mean by “good”. Watching a design debate play out at work I’ve been struck by the lack of actual concrete feedback about the proposed alternatives. Data wouldn’t eliminate politics and personality from the conversation, but (and here perhaps I am being naive) feedback couldn’t hurt. If it’s me in the room, I’d like to hear something more concrete than, “I don’t like Adapter Factories”.
Wonderful idea. I especially love how thoughtfully you listed the caveats!
I also think this could be a helpful data point. And I fear that some or all of the caveats will render it useless (or even harmful) in many practical contexts :/
I think I'm seeing some insightful and useful ideas for "objectively" (meaning "*numerically* scoring") evaluating structural changes against a history of functional changes. Would have to be manual work until it could be (partially?) automated.
And it's applicability seems to be limited in cases I commonly work, where we need to make decisions but it's man-weeks or man-months before we'd have code to experiment with. Like yes, we could "spike." But how valid are the numeric results from the spike? As long as we are respectful, rational, and reasonable, a few hours of discussion could be faster and cheaper than man-weeks of implementation, measurement, and then contentious evaluation of the "objective" numeric results.
Are "number of lines needed for a behavior change" and "locality of change" always the things we want to be optimizing for? Back when I mostly wrote dynamically-typed code, I would have said "yes", but after working with algebraic static type systems for a few years, I see things differently. I find that long-distance connascence is much less of an issue when my type checker tells me all the places I need to update. (Maybe the ease-of-change metrics could account for that? I don't know.)
The thing I mostly optimize for these days is readability. "Can you understand what the code currently does" is more important to me than "are future changes likely to be small". After all, I have to understand the code before I can hope to change it safely. Structure A is better than structure B if someone unfamiliar with both finds A easier to read (i.e. your point about "golf").
"Testing" Structure Changes
Wonderful idea. I especially love how thoughtfully you listed the caveats!
I also think this could be a helpful data point. And I fear that some or all of the caveats will render it useless (or even harmful) in many practical contexts :/
Cooool
I think I'm seeing some insightful and useful ideas for "objectively" (meaning "*numerically* scoring") evaluating structural changes against a history of functional changes. Would have to be manual work until it could be (partially?) automated.
And it's applicability seems to be limited in cases I commonly work, where we need to make decisions but it's man-weeks or man-months before we'd have code to experiment with. Like yes, we could "spike." But how valid are the numeric results from the spike? As long as we are respectful, rational, and reasonable, a few hours of discussion could be faster and cheaper than man-weeks of implementation, measurement, and then contentious evaluation of the "objective" numeric results.
Are "number of lines needed for a behavior change" and "locality of change" always the things we want to be optimizing for? Back when I mostly wrote dynamically-typed code, I would have said "yes", but after working with algebraic static type systems for a few years, I see things differently. I find that long-distance connascence is much less of an issue when my type checker tells me all the places I need to update. (Maybe the ease-of-change metrics could account for that? I don't know.)
The thing I mostly optimize for these days is readability. "Can you understand what the code currently does" is more important to me than "are future changes likely to be small". After all, I have to understand the code before I can hope to change it safely. Structure A is better than structure B if someone unfamiliar with both finds A easier to read (i.e. your point about "golf").