Why Automated Testing is Important – Part 2

Posted in: Software Development Best Practices

In Part 1 of this series I described the characteristics that make up a good Automated Test. Here in Part 2 of this series I will explore all of the benefits you will enjoy by creating those good tests and why the time spent on making good tests is a no-brainer investment.
Continue reading »

Why Automated Testing is Important – Part 1

Posted in: Software Development Best Practices

The adoption of Automated Testing strategies and tools, both in Agile and traditional teams, has been patchy – some teams and communities have embraced it, but many organizations still perceive it as a burden that just slows down development. Those that see the writing and execution of tests as an additional, costly and separate task from development have missed seeing some of the main benefits of an expertly manicured test suite.
Continue reading »

Coding Standards – Quality From The Ground Up

Posted in: Software Development Best Practices

Coding styles are THE religious debate of the Software Engineering industry. Everyone has an opinion, but no one has an iron clad argument as to why their ideas are better than someone else’s.

It doesn’t matter what language you write your code in or what company your work for or even what open source project you contribute too, the topic of coding styles will sooner or later raise its head. The debate can range from the banal, like which line the curly brace goes on, to the overly subjective, like how to name variables.

In the end most of the decision points are pretty subjective and it is somewhat irrelevant what you choose, as long as everyone agrees and you are consistent. But don’t be mistaken, a consistent coding style is an important consideration on any project, from the solo developer to the multi-national team.
Continue reading »

Get it right the first time – there is no going back!

Posted in: Software Development Best Practices

How many times have you been writing a piece of code and thought “Oh, that piece is going to be tough, I will put a dumb version in for the moment and come back and put the complete version later”. Probably often. Particularly if it is near the end of the project.

Usually this choice seems pretty benign, in fact it is second nature to most developers. But what are the issues with this approach?

The reality is that very few people ever get to go back and fix poorly written code. Even with the hype on refactoring these days, it really is not a widely spread practice (yet). Projects get pushed out the door prematurely to meet the almighty deadline and the team moves straight on to either the next version or the next project. In fact it is probably fair to say that if you have a bunch of time to be refactoring (assuming you are working on a “traditional” project where refactoring is a luxury at the end and not an everyday occurrence) that you are probably on a downward spiral in terms of job security. Your team should be 100% committed all the time – any other situation is probably a bad sign.

So what’s an engineer to do? Simple, just get it right the first time.

Getting it right the first time is actually spectacularly difficult for a whole bunch of reasons, many of which the engineer has no control over. What seemed perfectly logical will at some point turn out to have been a total waste or miscalculation. This is one of the main reasons the agile community has evolved. Agileists accept that getting it right straight off the bat is difficult, so they follow practices that limit the possible wasted effort by getting feedback early and often so they can more quickly identify when things are going wrong and change course quickly.

If you don’t have the luxury of working in a progressive company where agile techniques are embraced, you really have to be able swallow some hard truths. The biggest of which is, be careful what code you write as it will likely end up in a production environment and once that happens you will likely be supporting it for a long time, perhaps years or even decades. I once read a story (I forget where, someone please let me know if this sounds familiar), about a development team that wanted to ensure they did not commit too early to any technology or give customers false impressions about how much progress had been made, so what they did was literally prototype the UI experience with the customer using cutout felt squares and pinned them to a board and rearranging them until the customer had what they needed.

So think about what you are writing, quality is something you need to worry about now, not just during the QA phase of your project. And quality is more than just whether the code meets the functional requirements without setting the computer on fire. Quality is everything from following your teams coding conventions and code documentation, to extensibility and maintainability.

So if you are in an agile team, realise that the higher the quality of the code base, the more value it has to your company and/or your customer. To that end, refactor mercilessly. If you work in a traditional team, before you write a single line of code, think to yourself “would I want to maintain this piece of code I am thinking of writing” because that is exactly what you will be doing if you write it.