Design

Read more about the article Testing in isolation

Testing in isolation

  • Reading time:29 mins read

An AL developer gets fired from his job for writing inefficient tests. With his LinkedIn profile proudly showing off his extensive testing experience, a car manufacturer hires him to test cars. His first assignment: test the oil lamp. So he imagines a test, applying his vast experience:

// [GIVEN] A car
// [GIVEN] Enough fuel
// [GIVEN] Engine oil within operational limits
// [GIVEN] Engine runs long enough

// [WHEN] Oil level drops below operational minimum

// [THEN] The oil lamp turns on

Spoiler alert: the guy’s gonna get fired again.

Continue ReadingTesting in isolation

Gentlemen’s agreement pattern, or handling the “Handled” pattern

  • Reading time:11 mins read

I’ve delved deep into design patterns story with my last two blog posts, but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.

It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.

Let’s take a look.

Continue ReadingGentlemen’s agreement pattern, or handling the “Handled” pattern

10 reasons that make design absolutely necessary

  • Reading time:12 mins read

Unfinished buildings, by net_efekt (on Flickr)Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.

As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.

Here I list the ten most important reasons that I believe make design absolutely indispensable.

Continue Reading10 reasons that make design absolutely necessary

Setup-dependent requirements

  • Reading time:3 mins read

While designing a custom functionality for a customer, there was an issue with posting groups: the way the custom functionality was designed would result in value entries being always posted to a single posting group, resulting in inventory balances always going to the same inventory account.

When I brought this issue to my customer’s attention, they said: “but we only have one single inventory account, and we only use one single posting group, so we don’t need this functionality to be smart about this”.

This was an example of what I like to call setup-dependent requirements.

Continue ReadingSetup-dependent requirements

A new book about Microsoft Dynamics NAV

  • Reading time:2 mins read

Back in my time (now I feel old :)) if you wanted to read a book about Microsoft Dynamics NAV, you just couldn’t—there wasn’t any available. Today, if you want to learn about NAV, not only there are books about programming and implementing, but with new Mark Brummel’s book you can now learn about the most important aspect of Microsoft Dynamics NAV customization projects—the application design. The book hasn’t yet been published, but is already available for preorder through PACKT Publishing at the following link: Microsoft Dynamics NAV 2009 Application Design.

Continue ReadingA new book about Microsoft Dynamics NAV

What’s New In Sure Step: Functional Requirements Document

  • Reading time:4 mins read

One of many improvements the latest version of Microsoft Dynamics Sure Step methodology has brought along is the revised purpose of the Functional Requirements Document (FRD). This document has long served as cornerstone of every Analysis process of every implementation project: it was the main deliverable of the Analysis phase and it both documented customer’s requirements and explained how they will be met with Microsoft Dynamics NAV solution.

Continue ReadingWhat’s New In Sure Step: Functional Requirements Document

Read My Lips: Why?

  • Reading time:6 mins read

Recently, a reader, commenting on my last post about Sure Step, pointed me to an article by Karl E. Wiegers
“Read My Lips: No New Models!” I initially responded to the comment, but I figure the comments aren’t read as often as posts, so I decided to blog it.

It’s doubly funny that the reader is using Dr. Wiegers to devalue and dismiss Sure Step: firstly, the article has really nothing to do with implementation methodologies at all, and secondly, when I delivered Sure Step training at WinDays pre-conf earlier this year, I gave to each attendant a copy of Karl E. Wiegers’s latest book “Practical Project Initiation”—at the time it was the best book available that matched both the message of my training and the point of Sure Step as a methodology.

Continue ReadingRead My Lips: Why?

Diagnostic Phase – a signpost for implementation

  • Reading time:5 mins read

Each phase of Microsoft Dynamics Sure Step methodology is equally important in an implementation project. You could argue that analysis is the most important, or that design is the most important, or that operation is less important. I’ll paraphrase Scott Adams here and ask: how one phase can be more important if each of them is completely necessary? Well, except for Diagnostic phase.

Continue ReadingDiagnostic Phase – a signpost for implementation

Architectures: Good, Bad and Ugly

  • Reading time:6 mins read

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. Most of the stuff he talked about reminded me of some bad experiences about architectures on projects I’ve worked on. Most of stuff here is also not my original contribution to the universal pool of knowledge, and I reuse it with the permission of the author, so Miha, thanks! What I did, however, is that I applied general principles to specific Microsoft Dynamics NAV situations.

Continue ReadingArchitectures: Good, Bad and Ugly