For many people writing BC Extensions, particularly folks that are coming from the older NAV C/AL development world, it’s very easy to fire up a new Extension, and then you stuff 100% of everything into that Extension. You publish to the client or AppSource, and done, right?

You avoid having ID conflicts, you avoid dependency circles (or even learning about them), and you can find everything in one big monster Mᴏɴᴏʟɪᴛʜ application. Solves everything, right?

It’s true, you avoid some problems. But, what happens when you have:
– a BC update with a breaking change
– multiple projects (approvers?) all at once making changes
– deployment problems
– change an integration
– 3rd party solutions added/removed

You then will find yourself slowly walking down the path of “maybe this one part should be its own extension”. Quickly, you’ll end up with a nice big plate of Dependency Spaghetti.

As we talked about in our BC TechDays session, there are better ways.

In the session, we looked at the example case of a company growing, adding new functionality over time, adding new integrations, and changing integrations (and dependencies) – the AmuseYou corp.

That was taken directly from the Workshop, where we reviewed, wrote, and rewrote versions of the AmuseYou solutions over the course of the day. The workshop includes exercises to develop the baseline knowledge needed, as well as how to grow.

In this class, we not only talk through all the rules and how to apply them (and how to explain them to customers & stakeholders), but we talk about practical ways to move your *existing* solution forward. How to migrate and evolve.