Hidden threat: critical points that are not paid enough attention after the end of software development

Enough to code and test the program is not enough.

Did it happen so that after starting the program, the employee who worked with her for a long time leaves? Or there is a need to modify the program, but no one remembers how it works?

You know the continuation: everyone begins to feverishly remember what kind of program it is, how it works, where it is stored and where it comes from, etc.

You must admit that such situations occur with enviable periodicity and occur all the time.

If the program does not have normal documentation, then it can be very, very difficult to restore its internal structure. And sometimes it even results in serious mistakes or a complete stop of the process.

Therefore, it’s good practice to at least create simple instructions for use (which can be replaced, for example, with screencasts for speed).

However, there is one point that few people pay attention to.

Let's look at it with a specific example ...

Imagine that you have made a directory of Russian cities, which is used, for example, when registering on your site.

Everything works fine, but a year or half a year passes and the names of many cities change (this is a completely real situation - the names of settlements change constantly).

How do you know about this? What will you do when you discover this?

And then what? Soup with a cat?

Will you wait until users start sending you angry letters with questions about where you shared their city? You are hardly interested in this, right?

Therefore, it is not enough just to make a directory. It is also necessary to foresee what will happen to him afterwards, after putting into operation.

Moreover, this part is unexpectedly important and rather laborious. But it must be done!

Let's finish the example with directories and think over the procedure for updating them.

You can update the directory in two ways: automatically and manually.

Of course, it is most beneficial to update automatically, but often this is not enough.

Imagine that the source from where you get the list of cities has broken down - it has stopped updating or an error has occurred on it.

If the error is still possible to somehow detect (for example, automatically send emails to administrators), the termination of the update did not find any (because there is no error, but the information is not updated)

is therefore more correct to allocate a special person who will be in the know on the directory and will be able to determine that it is not true.

Wow! The challenge is expanding.

It is the responsibility of this person to make a periodic check of the directory, and even better, add the task to his calendar and write instructions on what to do when a problem is discovered.

And in order to remember how the directory works in a year, it’s worth recording information about it on the wiki: how the module works, where and how the information is stored in the system, to whom letters are sent, a link to TK, what kind of person is needed to support him, and what are his responsibilities.

It turned out a full-fledged business process.

Summary

As you can see, writing and running a program is not enough.

Be sure to think about what will happen to your program further: how they will use it, how to keep it up to date and how to act in emergency situations.

The usual objection to this is: not enough time. Yes, time is always really not enough, but think about how much time you will lose later when you need to urgently take something. Believe me, the losses will be much higher and more expensive than now, when the program was just created.

Try to do video screencasts instead of text instructions - it's faster and easier.

If you want to make a finished product and take care of your users and colleagues, think over what will happen after your program starts working.

Just make a small checklist and use it for each of your programs.

And success in your work!