Smart Coded

We are developers we like to write code, we like to write a lot of code, we see code as the solution to all of life's ills.

The uncomfortable reality for all of us is, sometimes code isn't the answer.

We've all been in the position, especially early on in a project, where our imagination is sparked, our geeky sense starts tingling as we see a potential new feature starting to be mapped out in our mind.

My message is, do NOT code that feature, if its not on the list its not going in.

You Aint Gonna Need It

Whenever were trying to decide on a solution to a problem with been presented with we should be seeking to get away with doing as little as possible, we should be trying to do the simplest thing that can possibly work.

Its a harsh reality but code is a liability not an asset, we should be in the business of ensuring we need as little of it as possible.

Code has to be maintained, code has to be tested, code has to be integrated with other pieces of code. It has to be documented and it has to be understood by anyone new that comes into contact with it.

All of those tasks take time and effort, the only way to effectively reduce both is to write just enough code to implement the required features and to implement them as simply as possible.

We'll I Didn't See That Coming

What may seem like a time saver at first, "I reckon where going to need this at some point", can end up costing a lot further down the road when the code has gone in a direction we didn't anticipate and the code that implements a feature that no-one asked for or is using still needs to be maintained.

One of the fundamental things an agile methodology tells us is that things are guaranteed to change and the intentions and behaviour of users is difficult to anticipate.

When we decide to implement a feature no-one asked for we are unlikely to have properly defined what it is were trying to achieve by adding it, remember allowing you to write a cool piece of code isn't the end goal.

Implementing one feature often leads to other features before long if were not careful we've created a whole mass of stuff no-one actually wants but we have to keep the plates spinning.

An agile code base is a small code base that is as simple as it can realistically be to meet what's being asked of it. Good engineering solves problems and believe me there are enough of those to go around we only need to concentrate on the one were being asked to solve now.

Coding Smart

So we write a really simple piece of code and then rip it up and start again when we need to solve a new problem or implement a new feature? Well no, we write simple but SOLID code so that we never need to start again we just refactor, change and adapt.

Although it sounds slightly strange to say SOLID code is flexible code, those five principles will ensure that when you do get the inevitable tap on the shoulder asking for a change the new road ahead will be clear.

When your writing some code and you do get the itch, "we could easily add in something that does this as well", the battle is already won the fact that you can see how that would be done is enough to prove you've solved the problem in the right way, what your really seeing is flexibility. 

The chances are the thing your anticipating won't actually be required in exactly the way your envisioning it but if your code base is flexible and built for change then it doesn't really matter, it'll be able to cope with whatever the world throws at it.

Keeping it simple and holding back the urge to churn out more code isn't easy but there is no more valuable skill a developer can learn than becoming adept at knowing when not to write code, its not laziness its smart.