Tag: Software

Who is looking at your code?

We’re software developers and we take our art form seriously.  Our palette is the editor to which we lay down our beautifully crafted code.   How we name variables, how we shape methods and how we format code, leaves its own unique DNA sequence that can quickly identify the owner.   Even after running code through a standardized formatter, the author is not immune from detection.

Software development has always been a group effort.   If you write code that is never seen by another pair of eyes, then you aren’t really a software developer.  A hacker at best maybe.  The worse thing you could ever find yourself in is being the only developer in the company.

I bet some of you are thinking that sounds wonderful.  No one telling what to code, how to code, silly release procedures having to be followed, tickets to be created/updated, what language to use, the list can go on.   However, how would you know if you are any good?   How would you know if what you are creating is top quality?

The simple answer is you wouldn’t.   Sure you can read as many forums, mailing lists and books on coding as you wish, but since no one is forcing you to follow any of the process, no one is keeping you in check and challenging your ideas and thoughts.

Developing software is like having sex – best enjoyed in at least a pair, if not more, but never a solo affair.

The best developers in the world have that one person in their lives that they can go do and have them say “yeah, that is not bad, but what if…” and leave you wondering if the solution you just designed was as good as you thought it was when you first presented it.

Challenges is what makes our designs great.  A challenge will ask the questions we never dared to ask or even thought to ask.  A challenge will let you tighten up areas that you assumed wouldn’t need any explanation (“I mean that section is obvious isn’t it?”).

If you write code that is never seen by another pair of eyes, then you aren’t really a software developer.

A challenge doesn’t necessarily have to be a complete interrogation under the spotlight.  It can be as passive as a code review with a simple question “why did you do it this way?”.   That question can quieten even the most hardened developer as they try to recall the reason they have constructed a method/loop like that because while it made complete sense at 2am in the midst of a caffeine induced coding marathon, 3 weeks later, in the cold sober light of day, it makes little sense now.   What is even more baffling, is that it works!

Your code needs eyes.  The more eyes you can get to look at it the better it will be.  Who knows, you may have got it right it from scratch, but at least with more eyes looking at it, you will have that validation.

A good code review isn’t pouring over single line of code, determining if they have used the right method or API call – an experienced developer will be able to see that quickly with a quick glance.   It isn’t about how the code looks in the editor either, chances are you should be all using a standard code formatting template that brings everyone’s code to look’n’feel the same.

A good code review is making sure all the components are put together in a logical manner that is maintainable, readable and flexible enough for the future requirements that may be made of the component under review.   In most cases, code reviews will always result in code being removed, rarely added, due to the fact that developers have a natural tendency to over complicate instead of over simplify.

The next time you write a piece of code, or design a system, invite someone over to take a look at it and let you walk them through your thinking to see if they agree with your conclusion.   If they agree with you, then thank them kindly and ask them to move along.  You want to find that person that will disagree with you on at least one point.

Once you find that person, keep them close, they will make you a better developer.

How’s your Software Insurance Policy?

Ask any software developer a list of things they dislike doing the most and chances are testing and documentation will make the top 2.

Testing is one of those necessary evils that every software developer must wrestle with.  Software developers have a unique confidence (read arrogance) that the code they write is error free and production ready as soon as their fingers leave the keyboard.  We don’t need to test – it is perfect as it is!

Wouldn’t the world be a nicer place if that was the case? Sadly such hubris and confidence has killed many projects success and dented many a teams or individuals reputation.

There are many types of testing available, but the one developers are usually most familiar with is that of unit testing.   This is when you take a small piece of code/method/class and subject it to many different inputs observing its behavior and output for anything out of the ordinary.

There are two major trains of thought when it comes to unit testing; test-driven development versus post-development testing.   It doesn’t really matter which one that is employed, but one thing is for sure, we never can do enough of it.

Unit testing is a bit like buying fire insurance.  Fire insurance is there to help pick up the pieces when the worst happens and your house catches on fire.   The vast majority of people will never experience a fire in their time and as tempting as it is to stop buying the insurance, we still can’t bring ourselves from canceling the policy.  Yet should fire strike, we may find that we are woefully under insured.

Unit testing is like that. You can go for long periods of time, with your unit tests never highlighting any problem.  You get lulled into a false sense of security, that the code you are writing is perfect and the sprinkling of testing you are doing is merely confirming that.  Of course, there is the huge possibility that your test code is not as thorough as it could be.

But every so often, our insurance policy kicks in.  And when it does, we feel a joy and sense of occasion that all our efforts and work in the past have paid off.  We’ve been saved.

A unit test, is coding for the future – you hope your unit test will never fail, but should it, then you have just saved yourself from a huge and potentially embarrassing problem.

Image and video hosting by HilariousGIFs.com

Unit testing is one of the most important insurance policies a developer can purchase and while tempting as it is to let your payments slip, one day you will wish you had paid more into the insurance fund.