Development Best Practices
“Best practices” is one of those beloved and hated concepts. There are people who just embrace “best” practices for the sake of their bestness. And there are people who just…
“Best practices” is one of those beloved and hated concepts. There are people who just embrace “best” practices for the sake of their bestness. And there are people who just…
It’s official now, and it’s time I announce it here: after two years at Microsoft I’ve decided to take the helm of my career and venture into the realm of independent consulting. Two days into it, and all I can say about it is: what have I been waiting for this long?
While at Microsoft, I had a chance to work on some very exciting projects, I was sitting at the source of information, and the thrill of being able to know about all the news and developments before anyone else is priceless.
But the thrill of being able to work on my own, to pick my own projects, to take on completely new challenges, was even more priceless.
I’m not sure about you, but I’ve missed last week’s update to this free download from Microsoft Download Center: Microsoft Dynamics NAV 2009 Developer and IT Pro Help.
Published in December 2008, this set of help files and guidelines contains valuable information for developers and IT professionals about development, debugging, installation, security and similar best practices.
Implementing a new Microsoft Dynamics solution doesn’t merely introduce a new piece of software into your environment. Yes, the software is an important part, you need to deploy it successfully, configure it as necessary, probably even customize it and change the business logic under the hood.
One component, however, is easily overlooked, and you wouldn’t believe how often it’s not addressed until late. Or too late. It’s the infrastructure.
Infrastructure is tough. It’s not just servers and desktops with some wires, switches and access points in between. Its a lot more. What kind of hardware do you need for your servers or desktops? What kind of performance do you really need? What kind of network layout is optimal for your transaction volume? Should you run the client on desktop machines, or would a remote desktop access be a preferred method? Do you virtualize your servers? What kind of failover capacities do you need? Can you retain any of your old hardware? How many users will use the system? Tomorrow? In five years? What about interfaces and integration to other systems or applications?
A couple of wrong answers, and down you go.
(Three compelling reasons to reshape your business processes, not your software)
Has your computer ever crashed while you were doing something important, causing you to lose all your work? A natural first reaction to this situation is frustration: your work is gone, your effort went in vain, you’ll never do it as well as you did it the first time…
And yet, when initial frustration is gone, and you start doing it over again, from scratch, you are more likely to produce results of higher quality than the first time. Why? The reason for this is simply called—experience.