You start coding - I'll ask what they want.

I have found myself in a rather unique position. I am working as a developer on a project in which I was the analyst that wrote the programming specifications. As a result I am finding that I approach problems differently when wearing different hats. As an analyst, I think I write decent specs, mainly due to my programming experience. It is really interesting to find myself on the other side of the fence having to chomp my way through garnish and trimmings, in order to find "the meat" of the problem. This experience has challenged the way I approach solution design and programming work and will hopefully allow me to improve in both areas.

When I wear my analyst's hat, I expect certain things from a developer. I expect that they will read the spec first. It seems obvious but you would be surprised at how often I get called to explain details around a solution design when the developer has not actually read the spec. With my analysts hat on I would suggest the following steps to programming against a spec:

1. Read the spec.
2. Read the spec again.
3. Ask questions of the analyst/domain expert to clear up any areas where you are not entirely sure what is meant.
4. Plan how you are going to implement the solution and break the spec down into a series of "programming tasks".
5. Code the programming tasks. Make sure you test your work as you go.
6. Read the spec again. This time you can "tick off" all of the tasks that needed to be completed. Maybe you missed something the first time around.

I also expect that if I have written a spec for something that will simply not work, or could have been done better, the developer will call me and discuss the solution. I do not think I know better than other people, I just know that without a solution design, nothing will happen.

Now I hope I can follow my own advice. So far - I am finding it hard work. The temptation to start coding at the first bit of the spec I understand is almost overwhelming. Developers just love to get coding!

Programming Microsoft Dynamics NAV

A new book by David Studebaker covering Programming Microsoft Dynamics NAV is on the horizon and, if you are quick, you can still get a pre-order discount from the PACKT publishing site.

Unlike the guys on Dynamics User that have commented on Mark Brummel's blog posting, I have not met the author, so I cannot vouch for his experience; but, I am looking forward to getting my hands on a copy. If David Singleton, Erik P. Ernst and Mark Brummel are saying this guy knows his stuff then it must be good.

I have been working with ERP for a number of years and have always been disappointed in the lack of books available for the products I have used. Go to www.amazon.com and search for Dynamics NAV or Navision and you will see what I mean.

Hopefully this is a sign of things to come. I am keeping my eye out for "Configuring Dynamics NAV for Dummies" ;-).