KISS - Keep it simple, stupid.

I'm a big fan of simple code, probably because anything more complex confuses me and I'll never understand it. This is a hard lesson which I learnt when I was about 15 or 16. I had written a very clever platform routine in assembly on the spectrum. It would draw a Manic Miner level using likes and some king of direction control. However, it was so clever, that after I had written it, debugged it and it was fully working - I had NO idea how it worked. Not a clue. Now, I'll cut myself a little slack here... I was only 15 or so, and had hadn't been doing assembler that long really. Still, I had written it, so I should have understood it! Since then, I've followed the KISS philosophy. Keep it Simple, Stupid. Although the original was apparently Keep it simple and stupid, I prefer the newer interpretation, as you really don't have to be clever to be an engineer these days (particularly a software engineer), and we love to complicate things; so I prefer the insult. If you haven't kept it simple, then you're stupid.

I see this everyday at work, coders who think the latest shiny blog posting about some cool new method is the absolute BEST way to code, and anyone that doesn't is mad! MAD I TELL YA! Well, thats obviously rubbish. If you follow every posting by some new publicity hound, then you're codes going to be terrible, plain and simple. The only real rules for coding is that its got to be clean, readable, fast (enough), maintainable and extendable.

Outside of these simple guidelines, nothing else matters, and it's simple a personal choice. You can throw other things into this mix, like testable, abstracted etc. but these can cloud the code to the extent that its none of the things it should be. I've see code thats been abstracted so much, it's beither readable, fast, maintainable OR extendable. A little abstraction is a good thing, but only when you need it. If you're writing a bit of code for windows, and it's never gonna be moved onto any other platform, then why abstract windows calls? If your going to add value to them (but having them do more, or make the API easier), then thats fine. But never add layers for the sake of them. You should never end up with an API that just passes things through directly unless theres a damn good reason (moving platform it a good reason, as you're wanting to hide the underlying OS calls).

However, desire for coders (especially a novice/junior) to complicate things is pretty high, as is the desire to make a perfect API. Take it from me, thats an impossible dream. You might think it's great, but others will always want something different. The idea is to make an API as good as you can right now, and adapt as time goes on. In the world of professional development, it's all about getting products out the door, not going back over API's trying to make them absolutely perfect. They have to perform the job, and do so with an API that was as good as you could make at the time, otherwise, you'll simply never finish and go bust.

In the end, there's 2 types of coders.... Those that want to get things done and out the door (and this doesn't automatically mean bad code!), and those that want to polish things and write docs, and make things pretty, but ultimately cost you dearly.

Oh...and if you've never seen the second kind, then your one of them!