This blog has a great title 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.
Avoid Failure
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.[1][2] 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.
This result of focusing on the happy path is the required functionality is created by leaves room for bugs when the users stray from the happy path into the alternative path or the exception path.
Developers are prone to following the happy path and only happy path testing because from their point of view they don’t often consider the real world use of the functionality but see the problem from a code point of view. It isn’t obvious to developer why end users would supply different values to what they are expecting.
Happy path testing can leave gaps for nulls, incorrect values and error checking/validating code.
The other area bugs come in is, is developer under estimate the random actions of end users.
Developers are not good testers
The paragraph raises a good point, developers often are poor at testing. Developers are so poor at testing their own code it’s considered good practise to get other people to test the code.
One of the reasons CRM developers miss bugs in CRM is they test everything using the System Administrator role which I have written about in this blog
The System Administrator role is a benefit and a curse to CRM developers
Developers often 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 but 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
Why CRM Developers should unit test their code
Experiences of Unit testing with Microsoft Dynamics CRM Projects
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.
More reading for you
Filed under: Hosk CRM Dev, Hosk Stuff, Hosk’s Microsoft Dynamic CRM Development
