February 2008

Policies are sacrosanct. Every company has them, and when implementing ERP systems policies do come in the way. That’s the way we do it ’round here since forever , is heard rather frequently, but a simple question why can leave a big question mark hang unanswered. There was an experiment… Five monkeys were put in a cage.

In Croatia, most of roads resemble battlefields. They are so full of holes and patches from all kinds of repairs over time, that they have to re-pave them every five years or so. It is an awful waste of taxpayer’s money, and makes you wish for the world of Jennifer Government to come be.

Development is an important phase of implementation of a highly-customizable ERP system, such as Microsoft Dynamics NAV, and that’s why I put a lot of emphasis on development, specifically on coding part of it. I’ve tried to cover a few do’s and don’ts of coding, but so far I’ve left one of my favorite clay pigeons out: hardcoding.

When I posted my last relevant post on this blog, I’ve got a comment from infonote (a visitor) how bad it was that Microsoft Dynamics NAV can’t use a versioning system. Well, as the matter of fact, it can. One of the nice things in NAV is that at any given moment, the development environment is just a Shift+F12 away.

I’m still in Vegas, and this city is crazy. But it’s funny, us people in IT have a thing or two to learn from these people in gambling business. We have all been hearing from our customers how they want their systems reliable, available, and so.

Although I really planned, and I really wanted to, I don’t think I am going to post anything useful in next few days. I spent last week in Seattle, attending TechReady conference, and now I am taking three days off – in Las Vegas.

Few days ago, when I wrote about coding, I didn’t have a slightest idea that at the same time, at the completely opposite part of the globe, Dave was blogging almost about the same thing . It is interesting to know that I am not the only one out there actually worying about code, and how it looks like.

Today, I got an e-mail from a reader of this blog, who asked me to help them with an actual problem on a project. Their customer is a small manufacturing customer in textile vertical. Whenever they calculate consumption, quantities for certain items get rounded to full numbers.

Code is boring. It is geeky. And it’s ugly, too. In C/AL it is especially ugly. While contemporary development tools come with all sort of gizmos which make coding easier, such as color-coding, auto-completion, refactoring, etc., C/AL editor seems like having awaken from a thousand-year sleep.