A guy came around last week. We met in a technical environment (IBM) so it was good to talk vaguely technical to somebody, and of course I told him about the application that I am currently up to.
I only worked with him for a few months, the role at IBM was my first contract so the priority was simply to prove that I was good enough to do the job, rather than worrying exactly how interesting the project was. As it happened the IBM role was not-at-all challenging, I got out as soon as the contract finished, and I went on to do many more interesting roles both locally and in London. His job was to support, rather than develop, one of IBM's flagship products, MQ Series. I make the point about "support" because IBM had a definite structure where developers developed, they were the glory boys, and supporters supported - there was limited crossover between the two. Rightly or wrongly - as a consultant on a specific project, I worked separately to both, although geographically closely. . But this guy obviously got very intimate with that one product, and eventually he himself became a consultant. I know myself that there is a small but well-paid market for MQ consultants (i.e. people who can configure systems to use it), whereas my skills included only a small amount of MQ - I've used it a few times since - but lots of other things too. By the sounds of things, the chap spent a lot of time not working, but when he did, he would have been well paid. It's a very niche market.
Anyway I talked to this guy about my application. He had a few thoughts. Some were off the planet (the environment in which I'm writing is very different to the environment in which he wrote), some were things I'd already thought of, but some did force me to think. I mean, most of my application is developed now but there are a few bits and bobs to complete. In software development, you start off with a vague notion about how you'll go about something, then put flesh on the bones as you make progress. For that reason it is difficult to cost projects up-front, but experience, where you've seen such-and-such a problem before, is invaluable.
One such area was the multi-user aspect of my application. I had a vague notion that the application would be written for one user, the currently-logged-on user. But would be usable by other people just by virtue of different users having different Windows logons, different file areas etc. Certainly my app is all files, so I'd always thought that it would be possible to have many different DIEM data files, in many different locations. But I got to thinking over the weekend, how exactly would I make it happen?
I didn't do anything until this morning, when I decided to check that the application would work for mutiple users. In the end it was easy, just because the application is pretty modular already so I only had to change a couple of tiny things.
But of course the big win is knowing not just that I want to do it, and knowing vaguely how I would do it, but having actually implemented it, I know exactly what steps I had to take to accomplish it.
At one extreme, I could have had my own database of users, passwords, data etc. but I decided that was too much overhead, and that the data here is not critical enough, plus I want the application to be as open as possible At the other extreme, I could have had no security whatsoever, just to keep the database in a single place, but the knock-on implication of that would be that I could only support a single user. So I'm in a halfway house, using Windows' inbuilt security features to separate users. I wouldn't claim that it is 100% foolproof - I am an administrator on the machine and I can see everyone's area (I happen to be the only person who uses it) - but the application is as secure as you make Windows itself, and that seems fair enough to me.