A day comes in the life of every programmer when they have to refactor someone else's code, or their own code, or fix a bug (heck, programmers spend a lot of time debugging someone else's crap as far as I know) and all hell breaks loose while deadlines tighten their noose around the neck. Here are a few simple practices that one can put to use in order to ease much of the future pain. They're not specific to any programming language, but generalizations which help keep things clean and less cluttered. They WILL not eliminate all your problems, but assuage it a bit, or perhaps a lot.

When writing an interface, method, function or any boundary to a block (a small system), never trust anybody; not even the future you, or the past you. Simply, don't assume. There will always be somebody who will disobey interface specifications, if one exists. We all have bad days. Always, always, always check data consistency.

(Image Source)

Document heavily. No matter if it is absurd, no matter if you're writing just for yourself, not even if your documentation becomes the butt of meme jokes. Tell yourself what you are doing. Know what you are doing (isn't that an oxymoron?). Write a symphony, tell a story. Murphy says that an issue will arise the moment you've let the memory of the code recede. Murphy did not explicitly say that, but I'm not saying that Murphy did not say that either.

(Image Credits)

Take what you need, not what you want. Especially C coders, I know boilerplate is fun and all, but in the end, if you wanted just the rose, and an elephant came along, holding it in his trunk, you might not satisfy the dependencies. Don't just include the stdio.h if you will never use it (okay, I'm kidding, you may include it, if you know what you are doing). Besides, you do need a minimal boilerplate in web-design till the point you can make your own.

Don't modularize if a monolith would work. Provided you know what you are doing, always start with a whole, then, depending on the complexity and code reuse factors, break it into smaller reusable wholes. "Premature optimization is the root of all evil". Don't distribute until it starts to become unmanageable. Don't hold back distribution thinking you can handle anything.

(Image Source)

To take care of the above step more effectively, do it on paper first - a pseudo code, verbose descriptions, essays, anything that you are comfortable. Achieve it on paper first (or a notepad) and touch the code screen only when you know what you are going to do it, and how. It has the advantage that design comes first, supporting code comes later, so you'll see the patterns and methods more clearly. As it goes "Design is the first sign of human intention". Or else, be prepared to run in circles and come out squares (I don't know what that means actually).

(Image Source)

But even after all of this, let it be clear that Software Development Cycle will never cease. You WILL have to refactor, there WILL be bugs, or feature requests, and you WILL have to modify your code. It is called evolution in Darwinian terms, it isn't meant to be perfect in the first shot, but should be robust and easy to evolve in the long shot. OOPs has 'ease of evolution' as one of its core philosophies.