Writing code to sketch the first core feature of an application could lead to a point where the next feature has to be realized roughly, too – just because of trivial dependencies. The code-base grows and when you are unlucky the overview of the sketches gets lost. However keeping the code-base clean and open for the future has to be a goal and can be achieved by applying the SOLID principles.
It might smell and looks like to much effort to keep the code clean in this early stage of a code base. Doing this is only valuable if it is done experienced and in a flat decent way. I.e. find a good trade-off between the benefits and the needed efforts to keep the code base more or less clean during sketching.
But there is another benefit. Sketching is cheap and applying SOLID principles, respectively playing with them, during sketching is an opportunity to practice and a possibility to talk about approaches with peers.
However if you apply the SOLID principles to keep the code base open for more sketches don’t forget:
The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.
(Extracted from: Getting a SOLID start)
More about SOLID:
Agile Principles, Patterns, and Practices in C#