Thursday, December 28, 2006

Get On With It

When I first started out doing software development, I worked for a military contractor developing an aircraft parts warehousing system for the Royal Air Force. My role was quite junior: I was given database schemas created by the older and wiser analysts and my job was to create “input screens” for maintaining the data in the database.

The analysts left as soon as the schemas had been handed over to me, leaving me alone “on site” to create the screens. I had no idea what people in the Airforce actually wanted the system to do, but maybe that wasn't my concern. Still, it worried me a bit, so I phoned my boss back at head office to find out. He told me to not worry about it at this stage and “get on with it” for a month, after which a senior analyst would visit me to review my work.

For the next couple of days I wondered if I wasn't smart enough for the job: I knew I had to “get on with it” but I just didn't know how. In the end, I did the only thing I could think of: I distracted myself by playing with technical features of the database until I at least knew something useful to me (if not actually useful to the eventual system user).

After a while digging deep into the technology, I found that I could create “input screens” really quickly, and even invented a “framework” that made it simpler still. The framework interrogated the database schema and generated most of the necessary input screens automatically, which I then only had to “hand tweak” a little. Focusing on technology proved to be a satisfying refuge for me – allowing me to keep busy and have fun at the same time, and push aside some of my nagging doubts about the usefulness of my work.

Within two weeks I had dozens of input screens. Within a month I had them all. Of course, I was still a little worried that I was alone doing all of this, and nobody had given me any feedback about what the customer really wanted, but at least I was making progress. I would save up all my doubts for the senior analyst's visit.

Right on time, the senior analyst arrived to “check on my progress”. The first thing he did was take me to lunch. It was a nice meal. I asked him lots of questions about my worries, and he promised he would look into that when we got back to the office. Back at the office we sat down at the computer and he asked what I had been working on. I told him, and gave him a short demonstration of the input screens. I also asked him a stream of questions along the way, and he admitted he couldn't answer them. I was disappointed to find out that out he didn't know anything about the project at all. His job wasn't to help me out, but to check that I had at least been doing something during the past month. At the end of the day, he told me how impressed he was. Before he left, I asked him about getting some feedback on the actual requirements, and he told me I was scheduled to give a demonstration to the client in a week and could ask my questions then.

A week later, I sat in a conference room with lots of senior managers from the military contractor. They told me I was going to show the system to the most senior officer on the airbase, and I shouldn't make waves when he was around because we were “down to the last two” in the shortlist for getting this project and this project was “worth a lot of money to us”.

The senior officer arrived, and I gave my demonstration. He smiled a lot, and shared jokes with my bosses. We all went off to lunch, and they swapped stories about people I had never heard of. After lunch the airforce officer asked me to demonstrate the system to his junior staff who would actually be using it to manage the storage and movement of aircraft parts around the world. Well, at least I now knew something about the requirements, if only a tiny morsel.

The junior staff arrived, and within five minutes pointed out that the system was nothing like what they had hoped for, and was far from what they needed. They told us that it appeared even less effective than the decades old manual system we were aiming to replace (which was news to me).

My bosses squirmed in their seats, and cleverly suggested we “complete the demonstration now and return to the detailed design discussions another time”. We finished the demo, the junior staff left, and the senior officer told me and my bosses “I will take care of my staff”. Which my bosses later translated for me as “he will keep the trouble causers quiet”. He did, and we never had any more complaints about the system not being what they wanted.

I continued to work on the system for a few more months, and then moved on to another project (an even more frightening one managing fissile materials). Another team took over where I left off on the aircraft parts warehousing system, and took the screens I had developed, “finished them”, and delivered them in exchange for a very large fee.

I don't know what happened with the system in the long run, or how on earth the junior aircraft staff managed to use it. I did hear, however, that they were still using the old manual system as a “backup”.

The whole experience left me feeling very uncomfortable. I thought it was a one off, and then spent the next twenty years finding out that it wasn't.

No comments: