For me the hardest part is when you find that your data structures are incapable of modeling the problem and you have to fix them somehow, usually by introducing some workaround. At once you had a clean structure and now it is full of hacks.
I write programs in small cycles of two phases, one in which entropy is increased, and one in which it is contained. I find that it is very hard that the initial design will fit as the program develops, so perhaps rather than polishing that initial design until it's pristine it's best to leave things in a "good enough" state so that they do their job, but you also won't feel too bad about deleting them later on.
Name:
Anonymous2018-11-08 4:16
The solution is simple. Don't fix the problem. Keep the clean structure.
Name:
Anonymous2018-11-08 5:35
if by ``clean'' you mean lacking in features, sure keep your software stale and featureless, while the competition adds more and more stuff, with occasional bugs, but the pros outweigh the cons and then your project becomes abandoned due to its lack of usefulness
Name:
Anonymous2018-11-08 7:39
>>2 fart is a subtype of butt which can be used the same way as shit? that makes no sense
>>9 OOP is often a square peg in a round hole, but disregard that. this makes no sense when judged by the OOP design principles. to be fair, so does most OOP in practice as opposed to OOP in books
Name:
Anonymous2018-11-08 8:29
hardest part is getting dubs and making others check them