I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
The first one is easy, design your interface right after you decide what a component is supposed to do, and then code to the interface. This has additional advantages, because you can use the interface specification to test the implementation as you go along.
The second one is usually a symptom of the first or third, and can be avoided by just making sure to properly specify your interface.
The third, when it happens, is often unavoidable. The ways to try and avoid it happening are pretty much the same as for any software project, do as much as you can to avoid having a hard deadline that is out of sync with a realistic estimate of how long it will take to finish things.
The fourth is best mitigated instead of being avoided, and is best mitigated by having multiple people review the interface design the same way you review code changes.
The fifth also benefits from review from multiple parties, but the most reliable way to avoid it is to have people who will be using the interface involved in it's design.
In all cases, the most common reason they're not avoided is either simple laziness, or the developers not thinking they're going to be an issue.
The first one is easy, design your interface right after you decide what a component is supposed to do, and then code to the interface. This has additional advantages, because you can use the interface specification to test the implementation as you go along.
The second one is usually a symptom of the first or third, and can be avoided by just making sure to properly specify your interface.
The third, when it happens, is often unavoidable. The ways to try and avoid it happening are pretty much the same as for any software project, do as much as you can to avoid having a hard deadline that is out of sync with a realistic estimate of how long it will take to finish things.
The fourth is best mitigated instead of being avoided, and is best mitigated by having multiple people review the interface design the same way you review code changes.
The fifth also benefits from review from multiple parties, but the most reliable way to avoid it is to have people who will be using the interface involved in it's design.
In all cases, the most common reason they're not avoided is either simple laziness, or the developers not thinking they're going to be an issue.
Awesome tips. Thanks for this.