Tag Archives: Hardcoding

Development Best Practices

image “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 shun them for the very same reason—those know-it-alls who have opinion on everything and know it better before even learning about it. What’s-best-for-you-is-not-best-for-me kind of people. Neither of approaches is actually, well, best.

For a best practice to be the best for you, you need to understand it, and if you find any pitfalls, improve it.

In two days I’m delivering the NAV Development Best Practices training for a service provider in Norway. They approached me two two months ago and asked if could do something like that. This brought to memory some good posts I made years ago, and here I bring the links. If you want me to share my best practices, this would be my starting point:

  • Code of Coding: emphasizes the need for understanding the effects of a change in code, and making others understand your intention
  • Code of coding 2: Documenting changes: about how to document different kind of changes in code, and also about the level of effect a specific type of change has in the long run
  • Code of coding 3: Die, hard(coding)!: about avoiding embedding output text into code
  • Code of coding 4: Die, hard(coding) 2: about avoiding embedding settings into code, with detailed explanation what exactly is wrong with it, and some good guidelines on how to detect less obvious cases of settings hardcoding
  • NeverENDing story: about a very bad example I once encountered, and how to avoid situations such as that
  • Featuritis Cure: now this one is definitely not a “best practice”, it’s about a situation when a developer pulled a prank on a customer so subtly that I just had to share it with the world. A far better cure for Featuritis (a dangerous and ugly disease indeed) is given by Mark Brummel, in his fantastic post Tip #20 – Save Report Usage. If you aren’t yet following Mark’s blog, now would be a good time to start.

If you are interested in development best practices, check these posts, and if you find them useful, then I’m happy. If you don’t, share your thoughts. Best practices develop over time, improving slowly, and gradually until one day they just become the norm.

WinDays 2008: Aftermath

WinDays 2008 are over. Somehow, this conference has become a milestone, in Croatian ICT community, in Microsoft community, even in my life. I met a friend there, one of those I only meet there, and realized just how quickly the year turned. Obviously, I contemplated too much, and partied too little, something to really get worried about.

Anyway, the presentations I delivered made me think about the future of this blog. It started pretty randomly, as a place where I simply dumped anything that crossed my mind, so you had all sorts of content, from programming, to development, to functionality, to theory. When I look at my blog to-do list, there is even more chaos to it, with topics ranging from SQL optimization all the way to business process reengineering. I realized I need more focus. Continue reading WinDays 2008: Aftermath

Code of coding 4: Die, hard(coding) 2

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. Anyway, as soon as they re-pave the roads, not a week usually passes before they come again, with jackhammers and heavy machinery of all sorts, and start drilling away, blocking the road in process and causing mass-frustration, just because some wacko has suddenly remembered that it would be nice idea to pass the optic cable underneath, or some valve started leaking.

Continue reading Code of coding 4: Die, hard(coding) 2

Code of coding 3: Die, hard(coding)!

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.

If you want me to define hardcoding, I’d probably put it something like this: hardcoding is the ugliest possible form of laziness, incompetence, ignorance, indifference, carelessness, or any combination of the five, which in short-term makes my toenails curl up, and long-term leads to poor and unmaintainable systems and unhappy customers.

Continue reading Code of coding 3: Die, hard(coding)!