One of our clients asked us why we release new versions of our workflow management software app and CRM so often.
image: the Waterfall Model is the general model of software development we follow to ensure that our clients experience only the most stable version of FieldMotion available (Maintenance in the model), unless they choose deliberately to use our testing (Verification in the model) server
We don’t really. Yes, there is always a lot of development going on with the field service management software, but this only filters down to the public once it’s been thoroughly tested. The only exception is when we fix an issue (such as today, we fixed an issue where exporting job data from the job management software, while applying a custom filter based on the customer name, ignored the filter), but the system is really so well-used now that there are no common issues left. Even if we fix 50 issues, you will probably never have noticed any of them before or after, because they’re all to do with using the system in a way that is uncommon.
FieldMotion is cloud-based field service software – we have maybe five different versions of it serving all of our clients. When we release a new “stable version” of the field management system (every six months or so), we start moving clients onto it from the older versions. Because we have many more field management software clients than we have internal developers, this means that the clients will sometimes do something we did not expect, and we then have to fix whatever allowed that to happen.
The stable versions are called “stable” because they are changed as little as possible. In the Waterfall Model of software development, these versions are called Maintenance versions because the only ongoing development they receive from the moment of release are maintenance updates. The only reason we change anything on the stable field service manager software servers would be to correct a bug. If a client insists that they need a new feature that we have not yet released on a stable field services management software server, then we move them to a testing server, because we do not develop new software on a stable field services management server. Of course, we only move them after first making sure that they are aware that the testing server is, by its very nature, not a stable server, and therefore they might experience glitches every now and then. This is their own choice to make. To wait for the new requested feature to be released within six months on a stable field service management systems server, or to jump the gun and move onto an unstable server that will have new features and tweaks almost every day.
With the app, we have “stable” points as well. Whenever we do anything new on the app, it’s added to a completely new repository version. Every repository version that we have has a specific purpose for its existence. For example, repo 73 was created to help speed up a form that a client’s field workers pointed out was slow. We spotted the issue, fixed it, and his mobile workers’ forms now load exactly 54 times quicker (yes, exactly). Everyone that upgrades to a new repository version gets the new enhancements that repository and all the preceding ones brings. This means that if you are on version 62 (optionally disable job ref editing on the app) and we upgrade you to 73 (speed up form-based calculations), then you also get the enhancements and fixes for everything in between.
We are always adding new fixes, features, and optimisations to our service software code, but we only ever upgrade people if it’s necessary (such as to fix a bug which we identify as possible affecting multiple people), or after we take a break at a certain repository version and decide to “rebase” everyone to it so we can have everyone on generally the same number again. Of course, we first put the app through yet another round of rigorous testing, but because later versions are by their nature more tested than earlier ones, we rarely, if ever (I really can’t think of a single case) come across an issue where we’ve broken something that previously worked.
To be honest, we probably update our stable servers much less than larger companies such as Microsoft do. I’m sure you are all familiar with Microsoft’s Windows telling you to please wait while it installs updates? Well, all software needs updates sometimes, but we try to make them in the background so you will never notice them.
So, to the client that thinks we release new versions all the time. No, we don’t. Yes, there are always new features being developed, and issues being addressed, but the only reason you would encounter all of those changes would be if you are a member of our development team, or if you are one of the few who are early-access testers for us.