The one point in this article that I will challenge relates to duplication of logic. The moment you've come across two similar scenarios that on the surface may benefit by a refactor and consolidation of logic, don't just instinctively jump to it. Refactoring to a universal model can take a great deal of time and effort. Days, if not weeks, may pass before your universal design is ready. Consider the cost of time and effort. Others are waiting for this work to be finished. Time is not on your side. Make sure you have a damn good business justification for consolidating designs and fight your biases.
I am advocating for knowing the costs and benefits of your refactoring decisions. If you can't predict what the costs are, take that as an indicator that maybe you should avoid refactoring, just yet. Consider as a litmus test discussing costs and benefits with people whom it will affect and try to reach an agreement. If you dread the thought of having that discussion, you probably ought to avoid refactoring. If you can't argue in favor of your refactoring idea, it's not worth the effort.
Also, consider that just because you can re-use flexible designs doesn't mean you will. You may not be the best person to consider the probability of re-use. Assume that it's unlikely: YAGNI (you ain't gonna need it).
I am advocating for knowing the costs and benefits of your refactoring decisions. If you can't predict what the costs are, take that as an indicator that maybe you should avoid refactoring, just yet. Consider as a litmus test discussing costs and benefits with people whom it will affect and try to reach an agreement. If you dread the thought of having that discussion, you probably ought to avoid refactoring. If you can't argue in favor of your refactoring idea, it's not worth the effort.
Also, consider that just because you can re-use flexible designs doesn't mean you will. You may not be the best person to consider the probability of re-use. Assume that it's unlikely: YAGNI (you ain't gonna need it).