As you describe it, you already have some sort of version control, though currently there are some issues with it compared to a typical version control:
An intentional commit in version control indicates that the developer strongly believes that the current state of the system would build successfully.
(There are exceptions, as suggested by Jacobm001's comment. Indeed, several approaches are possible, and some teams would prefer not trying to make every commit possible to build. One approach is to have nightly builds, given that during the day, the system may receive several commits which don't build.)
Since you don't have commits, your system will often result in a state which doesn't build. This prevents you from setting Continuous Integration.
By the way, a distributed version control system has a benefit: one can do local commits as much as needed while bringing the system to a state where it cannot build, and then do a public commit when the system is able to build.
Version control lets you enforce some rules on commit. For example, for Python files, PEP 8 can be run, preventing the commit if the committed files are not compliant.
Blame is extremely hard to do with your approach.
Exploring what changes were made when, and by who is hard too. Version control logs, the list of changed files and a
diff is an excellent way to find exactly what was done.
Any merge would be a pain (or maybe developers wouldn't even see that their colleagues were modifying the files before they save the changes). You stated that:
It's rare that the same project is worked on by two programmers
Rare doesn't mean never, so merges would occur sooner or later.
A backup every fifteen minutes means that developers may lose up to fifteen minutes of work. This is always problematic: it's hard to remember exactly what changes were done meanwhile.
With source control you can have meaningful commit messages. With backups all you know is that it was x minutes since last backup.
A real version control ensures that you can always revert to the previous commit; this is a huge advantage. Reverting a backup using your system would be slightly more difficult than doing a one-click rollback, which you can do in most version control systems. Also, in your system Branching is impossible.
There's a better way to do version control, and you should certainly consider changing the way you currently do it. Especially since, like Eric Lippert mentions, your current system is probably a lot more painful to maintain than any common version control system is. Having a Git or Mercurial repository on a network drive is pretty easy for example.
Note: Even if you switch to a common version control system, you should still have a daily/weekly backup of the repositories. If you're using a distributed system it's less important though, since then every developer's working copy is also a backup.