If you want to develop powerful software with speed, you need to be able to rely on your application. No fingers crossed when you deploy, but push the button with confidence!
Why confidence is important
Developing software is all about creating value for users and/or stakeholders. But what if you don’t ship because you or your customer is too afraid of application failure or crashes? You are not delivering value. And, even worse, the stack of features to deploy will only grow, and the risk of actually deploying them will grow with it.
So should you test all existing features by hand before deploying a new one? That will take longer for every new feature, thus slowing down development and increase cost exponentially.
Why you might not have confidence
There can be several reasons why you do not trust your application. A common reason is that some teams (or often their stakeholders) heap up new features because they are ashamed to show the feature to the world. They want it to be fully polished and blessed before they have enough courage to ship.
Another problem can be code quality. If an application is a mess adding a feature will be hard. The feature itself will probably be unstable, but on top of that you have no idea if you broke some other functionality.
Related is the lack of automated tests, having too few of them, or having badly written tests. When your test suite does not test all possible routes through your application, nobody will notice when any of the routes stops working or behaves differently due to a software change.
How to (re)gain confidence
Increasing confidence in your software can be accomplished in a number of ways. One important rule is simply to deploy often. The smaller the change that is deployed, the smaller the impact of a possible bug. Another benefit is that a smaller feature will contain less bugs. Also, having the right tools in place, you will quickly notice when something is wrong and you can deploy a fix quickly. As a last resort you will (hopefully) have a rollback mechanism to undo the deployment.
Good software will have a collection of well designed automated tests. End-to-end tests are designed to mimic user behaviour and test real application use cases - every deployment - automatically. Low level tests, called unit tests, can ensure all possible combinations of user input or user actions are checked.
These tests can complete in minutes, or sometimes even seconds, testing all your features after every small change you make. Automated testing will improve software design and catch most bugs before even making it to a release.
Peer reviews and pair programming
You can not expect a developer to write code and not make mistakes. But what if a fellow developer would take a look at the code? Peer-reviewing code is really simple, for example by using GitHub’s Pull Request Reviews. It is not about criticising people, but provide feedback about their code and spotting potential problems before they go live.
But there’s something even better than peer-reviews. When two developers pair program, they work together on a feature and peer review each other’s work right on the spot.
Try before you ship
Of course the automated tests will never cover all possible scenarios. So make sure before you ship, you give the feature a spin yourself as well. In addition you can ask coworkers, stakeholders or just randomly selected people to tryout your application.
When you have all this in place, there is no need to have any manual confirmation between having a “done” feature and deploying it. So configure your infrastructure to automatically release your feature when it is ready. When every single feature is deployed separately, you will know which feature to check when problems arise.
How is your confidence?
So what will it look like when you are ready to ship your next feature? Are you sweating bullets or beaming with pride?
At Kabisa we can help you boosting your confidence. We all know a lot about high quality code and continuous testing and deployment. Leave us a message if you would like to get in touch.