Sign up to the Decent Group newsletter.
Get monthly insights about how software can improve your business performance.
Subscribe now
How should an outside development team work with your own developers to minimise friction and disruption and maximise results? Over the years we’ve developed a successful approach to working with existing critical systems and in-house IT development teams. Above all it takes a thoughtful, ego-free attitude and careful transparency.
Our starting point is that we are in a supporting role, not a leading one. We are respectful of the developers who built and support your system. We have no desire to compete with them, only to complement their work. We will show them how we work, and we will want to know how they work. We’ll probably learn something, and they probably will too. This isn’t only about keeping everyone feeling happy. There are big practical benefits to working in this way – in particular it’s simply more efficient to work openly.
Our goal here is to build something that works for your users and works for your developers. However, that’s not necessarily easy to achieve.
First we carry out our usual process of understanding your system in depth, who uses it, and what they use it for. This often means we need to understand your whole workflow. Then we understand the problem you want solved – the extra part of the system you require. At this point we define the solution.
But then, instead of beginning our development work, there’s another essential step. We spend time with your developers to understand their style of development. This could include naming conventions, scripting standards, relationship diagram protocol, management of backups and so on. To make sure our work doesn’t jar with theirs, we adopt their way of working – or, if they like what they’ve heard of ours, we’ll use an agreed mix of ours and theirs.
At this point we’ll decide whether we do the development on a backup copy of the system or straight into the live system. There are advantages both ways.
If we’re making a completely new part of the system that doesn’t have an impact on other parts, then it’s sometimes worth building direct into the live system. No users will be aware of what’s happening as they don’t have access to it. Clearly we need to be careful though. Any disruption is immediately visible and immediately a problem. More often the right way to do the work is on a recent backup, without impact on the live system.
During the build we create and maintain our ‘Making Live Instructions’ document. This is written for people with FileMaker knowledge and explains in detail how to take the new software we’ve built in the backup system and put it into the live system. The document can be used by the in-house developers or by us – it’s valuable either way.
When our development work is complete we first internally review it before putting it to our client’s lead developer. We first show what it does, proving that it works. Then we show how it works. This covers things like scripts, layouts, field definitions, value lists and relationships.
This transparency really matters. We want your existing, long-term IT development team to take and own the new work. We may, for instance, have used techniques they have not seen before, so we carefully explain why we’ve done what we’ve done and how it works.
By the time we’ve finished our development work, the backup we’ve been using is out of date. It may have been taken in February but the live system is now in May. So we’ll take a brand new backup and do the making live process with this. We discover if the new part of the system still works. If not we amend our work and update the Making Live Instructions. We even time how long it takes to go live, and add this detail to the document, so that any downtime or disruption involved in the eventual release can be accurately anticipated.
Our Making Live Instructions document is itself thoughtfully produced to be as easy as possible to follow. It is structured in a standard format and order – something we have refined over the years. We’ve worked out an optimal order for making new software live. For example, we do custom functions first because they don’t depend on anything else. We do layouts and their part sizes near the beginning, but the objects that go on the layouts near the end as the buttons need the scripts to be there first. Doing it in this order is significantly quicker and involves less repetition and fewer errors.
Finally, once the new parts of the system are live, we show users how to use their new tools.
Everything we do when working with existing critical systems is about being thoughtful. In more ways than one: we not only think it all through carefully from multiple angles, we are also considerate about our impact on users and the existing developer team. This approach minimises errors, maximises impact, and makes everything easier both now and in the future.
Talking of the future, new tools are emerging that enable going live in a semi-automated way. One is called Otto and another Devin. We’re excited about these tools and we’re evaluating them carefully, but currently we don’t feel they’re completely ready to use in all situations, so our Making Live Instructions remain.
We’re open to change. The important thing is to continue to work in an ego-free way and be unobtrusive, supportive, and professional while delivering consistently high-quality results.
Fill in your details and give us an idea of what you’d like to talk to us about, and we will contact you shortly.