Design By Contract
Plan Before You Code
Many Moons ago, we were having serious bug issues with code at the company I was working at. No matter what developers did, bugs make it into Production and we constantly had to patch.
Part of the reason QA didn't discover some of the bugs was because of the complexity of some accounts.
Things slowly got better when a Senior Software Architect started implementing a Design By Contract coding standards
What is "Design By Contract?"
Design by contract is a different approach to programming. It promotes think-first, code-later in order to get a better quality of the software.
This is accomplished by defining clear APIs in the code between its various components. Each method needs to define what it takes as input and what the expected output will be. The output may be the return value of the method as well as a change of state of the enclosing object.
The great strength of design by contract is to have each method responsible for what it does and what it returns. It is on the caller to be responsible for what is given and the callee to return predictable results.
Ideally, contracts and methods are defined prior to actually coding the body of the methods. It is impossible to define the contract of something you do not know. This requires a lot of heavy thinking in advance which saves a lot of testing and unknowns later. It also makes the code easier to review and makes changes easier to implement as you do not have to guess about the context. Callers and callees state exactly their input, outputs, and what they do.
How did this Help QA/Releases?
Developers now had a better understanding of how their code works. It allowed other developers to understand how the code functions and pass the correct parameters.
When the code would fail there would be an assertion exception and it would be easy to figure out the issue.
Basically the Design By Contract moved the quality of code from QA to the Developer.
Five Things I Learned
It took a while to implement the Design By Contract throughout the system. Developers get used to planning before coding. Once they saw the benefits they were quick to adapt to the new model.
The Senior Software Architect worked with a small team of developers and a particular functionality within the software.
The Design By Contract coding standing stayed within the application long after the Senior Software Architect had left the team.
When testing code, QA would pay more attention to the logs and look for assertion errors - sometimes these would start as silent errors but would eventually turn into a serious customer-facing errors.
An interesting side effect: Developers were able to find serious logic issues with the Google AdWords API. This was interesting as other companies didn't report the issue. In some cases, Google fixed the issue, and in other cases, we worked around the issue.