Three little words... (by B)

I’m not a programmer... not anymore...
I used to cut code all the time but circumstances have conspired to push me towards managing other programmers and so now I only code when I have spare time (which is never) or when something goes wrong (which is rare :). However, I do help the programmers sort things out sometimes, even if it’s just by listening to them work through their problems.
Watching other people code is an exercise in self control for anyone who knows how to program, especially if they have different styles.
Most of the time this is not too bad, all of my guys are solid developers and I often end up learning new tracks as I go, but every once in a while I watch someone junior, someone with a lot of energy...
They bounce around code like a jack rabbit, writing a bit of code here and a bit there, they copy code into the buffer, delete it from the page, stop to make a few other non-related changes, and finally paste the buffer back into a new function - then they have to go back and debug 5 things at once.
It’s button mashing... (same way I play call of duty).
Worst of all, it’s all programming by impulse - “I’m facing this problem right now so I’ll code the first solution that comes to mind”.
Then later if they find themselves writing the same sort of code for the fifth time they might go back and try to make a function or a method.
There is almost no sense of planning and it results in code that is duplicated and complex.
Which is why I felt it important to write the 3 most important words in programming on the white board in my office:

DRY YAGNI KISS.

All you guys who had this stuff kicked into you when you were young developers can stop reading now - you know what I’m going to say and don’t need the lecture.
Anyone who thinks I’ve just described something you do at a party after one too many drinks, read on - you need this bad.

DRY - Don’t Repeat Yourself
Seriously, if you find yourself writing the same bit of code that you know you’ve already written then you should have put its generic form into a function to begin with. When I see large chunks of repeated code it makes it really clear that the programmer didn’t recognise common activities in the process. This tells me he didn’t understand the process before he started programing... or that he’s just not very bright.
I have to stress that not knowing the full solution when you start coding is OK after all hind sight is always 20:20, we do proof of concept work specifically to find out what we don’t know or haven’t spotted.
But the same process repeated in multiple locations in release code a maintenance nightmare - COPY AND PASTE IS NOT YOUR FRIEND - If you do the same thing twice consider a function or a method. You may decide that the two blocks of code are likely to diverge as more details get added (perfectly valid when doing RAD work) in which case drop in a comment, that way you can check it later in the development process and see if you were right.
Duplicating code without a damn good reason (and if it’s that good, it should be in the comments) is a bad idea, your code gets bloated and difficult to navigate. Even if you know every part of the code by heart right now the next person wont - and the next person could be you in 12 months after working on another project and forgetting how ugly this project really was.
Happy debugging...

YAGNI - Ya Aint Gonna Need It
Obviously you can go too far the other way, you can over plan and over architect, and it’s almost as bad as not thinking ahead at all. Don’t build factories until you need the product, don’t build generic function based versions of complex code until you are sure you’re actually going to call it from more than one location.
Finally, while I am a great fan of stubbing out functions until you get to them, don’t create stubs for functions until you are fairly sure that you’re going to get back to actually putting something in them - Your better of using comments again.
Unused code is just chum in the water stopping people from seeing the important stuff.  Empty and unnecessary wrapper functions just lay down a maze of code that’s easy to get lost in, and amplifies the maintenance overheads.

KISS - Keep It Simple Stupid
If you need this one explained then stop.
Right now.
Go to your employer, apologise and tell them you are too stupid to work as a programmer and only just realised it.
We’ve all heard the KISS acronym, there is a reason it keeps getting repeated - The simplest solution that meets your needs IS the best.
Full stop
End of discussion.
Every argument I have ever heard amounts to someone claiming some special condition, that should have been considered a need if it was that important. Think about what you actually need (or will reasonably need in the future) and what you don’t need (or are very unlikely to need in the future) and check you solutions against it.
This system works really well, you can plan and draw the most complex system you want, but when it comes to implementing - do what you need and plan for what you will need - stay focused and you will stay productive.

Wrapup:
Most programmers already know these rules, but everyone needs to be reminded from time to time. While we all like to call ourselves “hackers” it can be hard to own up to some of the bigger and cruder "hack" jobs we create every now and again. Whether it's enthusiasm or just time pressures, we all slip into some bad habits that we know are just going to cause problems later on. Thats when we need to review the basics.