Make sure your developers know what they are doing

This is a mistake I made once and wont make again. Last year I had to resort to external developers to assist on a project that had doubled in requirements but kept the same deadline. Thankfully the project consisted of several parts that were virtually seperate. There was some clue in the middle but the exact specification for that had been worked out from the get go. So there was no problem for the external consultant to get cracking on the system. There was only one problem. The application was very tied up to insurance laws and calculations. All the in house developers had worked in this area for a year or so already so they had picked up the basics and knew the logic behind how insurance works in Scandinavia. What I forgot was that the new developers this was all new and we were expecting them to figure out specs that were not detailed enough for people without the knowledge of the field.

Needless to say a lot of extra time went into explaining strange issues, and they didn't have the knowledge to notice when what they got explained by someone in sales or marketing wasn't what they really wanted. A lot of development go tossed out since once it was supposed to be ready it wasn't what was really needed, or it was too ridgid to easially expand to handle future additions or exceptions to the rules. It was frustrating for everyone. It is no fun being a developer on something that you don't have the ground work to figure out.

It worked out in the end once I focused more on being a part of their tasks instead of supervising the guys who knew what to do.

If I had to do it over again I would have sent the new developers on a 1-2 week course at our insurance academy for them to understand the basics. I think it would have been cost effective in the end. Less time spent on useless code and extra meetings, as well as increasig their knowledge and moral. If angled correctly it might even have been possible to have their employer pay for the course. It would also make it more likely that we would have employed their services in the future, but because the first experience wasn't great who knows. Mangement doesn't care about reasons much, just the bottom line. Bad impressions are hard to overcome.

So the next time I have to use someone to develop an application with a focus on a field of knowledge they don't possess I'm taking the extra time to teach them first.