Specification

Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.

(A short rant about eye-contact-based specifications.) In short, there is no such things as an eye-contact-based specification. And for a reason. While kicking-off of a project, we had a discussion with the customer about the change management approach, and specification detail.

A blog reader has asked me for help about an allegedly strange behavior of items with serial number tracking. They had a customer who had serial number tracking switched on for an item with FIFO costing method. Whenever they posted a sales transaction, they chose the serial number manually.

Four months ago I attended a conference, where I had a chance to listen to Miha Kralj, an architect at Microsoft, talk about architectures. It was one of the best presentations I ever attended, and ever since I had this topic in queue, but never really had chance to write about it.

The biggest jeopardies often lurk where we least expect them. When implementing an ERP system such as Microsoft Dynamics NAV, what should be one of our best allies, turns out to be our mortal enemy. It has a simple name: The Standard. Standard processes, standard functionality, standard documents, standard system.

About six months ago, when I was buying a car, a friend of mine, in a typical The Good, the Bad and the Ugly fashion, told me that there were two kinds of cars: good cars, and French cars. I bought a French car.