I think you’ve noticed that the consequentialism vs deontology debate happens in software design, just like everywhere else.
Y’know… funnily enough I actually didn’t make that consequentialism vs deontology connection even though my second to last post was about exactly that! Thanks for bringing it up though! I think you’re right!
The vast majority of things (factoring of your codebase, location and sharing mechanism for libraries, etc.) you can make lighter-weight choices, and test as you go—if it becomes annoying, then change it.
Yeah I agree here. And I think it’s a good point to bring up.
I think that in this situation, some form of what I was saying in this post regarding user research still applies. Say you make some lightweight decision. You’re then faced with the subsequent decision of whether you should change it. In making that subsequent decision, I think people probably err too strongly towards what the heuristics and acronyms say, and not strongly enough towards the user research of how easy to work with they find that the lightweight decision has made the code.
For example, maybe I see something duplicated once and DRY it up. I find that the abstraction I created is awkward to work with. But I keep it because I figure that DRY is good and is what I should do. Instead, it’d be better if I thought about user research moreso as the barometer, if that makes sense.
And even when doing user testing, there is usually NO WAY to resolve the “beginner vs expert” conundrum.
I agree that it is harder. Perhaps impractical in the majority of cases. But I’m thinking about a situation where, you have some design that has existed for a while, the users who have been using it have become experts, and you can do user testing on them at that point. Granted, you can’t compare two alternative designs this way (unless you do some sort of longitudinal A/B test).
Y’know… funnily enough I actually didn’t make that consequentialism vs deontology connection even though my second to last post was about exactly that! Thanks for bringing it up though! I think you’re right!
Yeah I agree here. And I think it’s a good point to bring up.
I think that in this situation, some form of what I was saying in this post regarding user research still applies. Say you make some lightweight decision. You’re then faced with the subsequent decision of whether you should change it. In making that subsequent decision, I think people probably err too strongly towards what the heuristics and acronyms say, and not strongly enough towards the user research of how easy to work with they find that the lightweight decision has made the code.
For example, maybe I see something duplicated once and DRY it up. I find that the abstraction I created is awkward to work with. But I keep it because I figure that DRY is good and is what I should do. Instead, it’d be better if I thought about user research moreso as the barometer, if that makes sense.
I agree that it is harder. Perhaps impractical in the majority of cases. But I’m thinking about a situation where, you have some design that has existed for a while, the users who have been using it have become experts, and you can do user testing on them at that point. Granted, you can’t compare two alternative designs this way (unless you do some sort of longitudinal A/B test).