The original title of this blog post was – Developers should stop being so happy. I found the old title amusing because over the years I have met some extremely grumpy developers. Classic old school developers who liked to sit in dark corner and not be disturbed.
The point of this article is grumpy developers can still skip and dance down the happy path when it comes to writing and testing their code.
I am continuing to read Code Complete 2 (it’s over 900 pages long it will take me a while), today I came to an interesting paragraph.
Petroski argues that many spectacular bridge failures have occurred because of focusing on previous successes and not adequately considering possible failure modes. He concludes that failures like the Tacoma Narrows bridge could have been avoided if the designers had carefully considered the ways the bridge might fail and not just copied the attributes of other successful designs
Developers are too happy
The process of development usually goes
- Requirements gathered
- Functional requirement specified
- Technical requirements specified
- Code written to deliver requirements
- Test –> fix bugs cycle
Developers often focus on delivering the functionality, which is often known as following the happy path
Wiki describes as the Happy Path
In the context of software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected. For example, the happy path for a function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.
Focusing on the happy path and creating the required functionality leaves room for bugs in production, when end users stray from the happy path into the alternative path or the exception path.
Developers naturally gravitate towards the happy path, often focusing on happy path testing. One possible reason for this behaviour is the developer doesn’t see the functionality from the end users point of view, instead the functionality is viewed primarily from the code point of view.
It isn’t obvious to developer why end users would supply different values to what they are expecting, how the end users will use the functionality or what they are trying to achieve using the functionality.
Happy path testing can leave gaps for nulls, incorrect values and a host of error checking/validating errors to slip into a production system because no one has tested these paths.
The other area bugs come in is, is developer under estimate the random actions of end users.
Developers are not good testers
Developers often are poor at testing, this is a badly kept secret of the programming world (developers often dislike testing as well). Developers are so poor at testing their own code it’s considered good practise to get other people to test the code.
One reason CRM developers miss bugs in CRM is they test everything using the System Administrator role which avoids many permission bugs, I have written about in this blog
Developers are not good at testing because after writing the code it’s difficult to step back and test the functionality rather than test the code. This is similar to writers editing their own writing, they feel attached to their creation to the extent they find it hard to evaluate it dispassionately.
How to avoid failure
An effective way of avoiding failure is writing unit tests for the code. The act of writing unit tests make the developer think
- What should this functionality do e.g. what am I testing
- What values (min, max) are allowed
- What alternative values might be presented
- What should happen when an error happens
Thinking before coding is always beneficial, sometimes developers are eager to get coding they miss this step out.
Once the code is written is unappealing for developers to write unit tests, so the best method of unit testing is to write unit tests while you create the code and use those unit tests to make sure it’s working as expected.
Thinking about errors and failures is very beneficial. You will capture and avoid many errors. The developer will decide how to handle errors and its usually a choice
- Fail fast, abort action
- continue and warn the user
Errors are not good but code which has blundered on and changed half the values it was expecting can make a greater mess and take longer to clean up, so it’s better to have a plan up front.
Don’t let these often simple errors slip out of your development environment to the end user, make sure you harden your code.
If you don’t write unit tests you should consider doing it
If you still are not persuaded to write unit tests make sure you go through you code and look for potential errors, validation checks. Make sure you have decided how you will handle errors in the code. It’s much better/quicker/easier to manage errors in a dev environment than having to add it in at a later date.