How do we keep your system reliable?
Many business leaders worry that custom software will break after a while and nobody will be there to fix it. This page explains what we do so that the system we deliver keeps working reliably after later fixes and extensions too.
How we keep the system reliable
We plan for later changes from the start
During development we build the system so that later bug fixes and new features can be tested easily and safely.
That way, after a change you can still check that the rest of the system works the same as before.
The full automated test suite runs before every new release
An automated test is a program that goes through the important functions of the system and flags anything that doesn't work as it should.
Before every new release, all of these tests run. We check the whole system, not just the new part, so a fix doesn't break something that used to work. This applies wherever the system runs.
If it runs with us: separate test and live environments
If we operate the system, meaning it runs with us in Azure, Microsoft's cloud service, we run two separate environments. The test environment is a trial copy of the system, while your staff work in the live one.
Changes are deployed automatically to the test environment, where they can be tried out. They only go live after approval.
Operation and support are two separate things
Operation
Where the system runs: with us, in Microsoft's Azure cloud, or with you.
Support
Who fixes the system and develops it further. You can sign a separate support contract with us even if the system runs with you.
Full documentation, so you are not tied to us
We write documentation for the whole system. It explains how the system is built and how to develop it further, and also how to run the tests.
If you don't want to continue fixes and further development with us, someone else can take over based on this. In other words, you are not tied to us.
What happens when you find a bug?
If we fix the system, a bug fix goes through these steps. The full test suite always runs, wherever the system runs. The test environment and the approval step apply when the system runs with us.
You report the bug
You describe what you saw and in which part of the system.
The fix is built
We find the cause of the bug and fix it.
The full test suite runs
All automated tests run, so the fix doesn't break anything else.
You try it in the test environment
If the system runs with us, the fix is deployed automatically to the test environment, where you can check that it works.
It goes live after approval
If the system runs with us, it only moves to the live system after approval.
If the system runs with you and you have a support contract with us, we deliver the fix tested, after running the full test suite.
What is different when your own system changes?
Updating ready-made software
The vendor decides what changes and when. You get whatever is in the new version.
Changing your own system
You approve what changes. The automated tests run after every change, so they protect the parts that already work.
What should you ask any developer?
Whether you work with us or someone else, it is worth getting straight answers to these questions.
Are automated tests written, and do they run before every new release?
With us: yes, the full automated test suite runs before every new release, wherever the system runs.
Is there a separate test environment, and do changes only go live after my approval?
With us: yes, if the system runs with us. Changes go to the test environment, and only go live after approval.
Do I get the full documentation, and can someone else take over the system if needed?
With us: yes, documentation is written for the whole system, so someone else can take it over.
Who will own the source code?
With us: the finished product, the source code and the documentation are all yours.
Let's talk about how this would work for you
You can ask us these questions too. In the first conversation we look at what you need and explain how we would keep your system reliable.