Raising The Bug Bar

In our quest to find the latest, greatest and bestest methodologies out there to ship great software we often overlook the simplest of implementations to get a project going – The Bug Bar.

As much as I wish this was an actual bar a la Bugs, it’s not.

bugs.jpg

The Bug Bar is a simple tool used to keep your team’s head above water when shipping copious amounts of software against an unpredictable schedule.

How it Works

Before each iteration set a maximum number of bugs that can be reported that cannot be triaged into a subsequent iteration based on their priority and severity to the project.

There is no discerning between bugs raised by Developers, QA, End Users or your mother – they are all created and treated as equal.

When that number is hit during the iteration, all feature and task development work is halted until the bar drops down to an acceptable level to then return to feature and task development.

What it Does

Ensures the team is focused on not rushing task and feature development by introducing bugs in the software that were previously not there but aren’t being worked on in the current iteration.

Ensures that the entire team (for business to project to development) are on the same page with this level of importance and know how to react accordingly when this happens.

Ensures your Project Manager is monitoring the bug lists and actively triaging what does and doesn’t apply (taking this load off of Developers).

Sets the expectation that the content is greater than the date.

It’s not a complicated concept, it’s downright simple, but sometimes that is where you need to start to see a change in the delivery of your software.

Troubleshooting Outlook Form Regions

Recently I had to debug a strange issue with an Outlook VSTO plugin where the plugin would install smoothly and load correctly but my custom calendar region was not showing as expected.  To complicate matters a little further, I had some clients on 32-bit and some on 64-bit desktop systems so it was not a straightforward install.

You can find the base steps for registering a VSTO add-in here.

Note: An easy check to see if your add-in is automatically loading correctly is to verify that the LoadBehavior key stays at 3.  You can keep the registry open while you load your Office application and refresh to see if it was unloaded.

Outlook Form Regions have an extra step though and depending on the desktop architecture you are on, you’ll need to create the following registry keys as well.

x32

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\FormRegions\IPM.Appointment]
"MySuperOutlookPlugin.Plugins.MyCalendarRegion"="=MySuperOutlookPlugin.Plugins"

x64

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\FormRegions\IPM.Appointment]
"MySuperOutlookPlugin.Plugins.MyCalendarRegion"="=MySuperOutlookPlugin.Plugins"

Where these values equal,

MySuperOutlookPlugin.Plugins.MyCalendarRegion – is the fully qualified name of your VSTO assembly and class name of the Outlook Region file.

=MySuperOutlookPlugin.Plugins – is the name of your assembly.

Once you have done this, restart Outlook and you will now see the your Outlook Region load appropriately.

Great Software NEEDS Requirements

I think it would be pretty cool to have had some IoT on my keyboard for all the code I have written to tell me how many lines I have written over the years.

But I would love to cross-reference that statistic with how much code I have rewritten based on poor requirements.

How much code I deleted?

How much code I had to update?

How much time was loss?

I generally try to keep to code on this blog but at the core of every great release are the requirements that are built at the beginning, middle and end.  Do a bad job on those and I can guarantee what the end result will be.

When jumping onto a new project or product, the first thing I always do is sit down with the user and the person writing the requirements so I can see how close they are to understanding each other’s visions for what the end product will be.

If they are closely aligned, I know we’ll be in good shape, if they are far apart, I know I have to plan for some additional work on my side to bring them closer together.

As much as developers would like to ignore this part of the process, they can’t.  Well-written requirements are the first step in a successful software delivery.

The developer’s role might not be to write the requirements, but their role is definitely to ensure that everyone has a complete and thorough understanding of the problem everyone is trying to solve as well as ensuring that the requirements stay true to that focus.

I published a Presentation on SlideShare a few years ago on How to Write Great Requirements, the content is as relevant today as it was then.

 

Registering Plugin Processing Steps

I was wracking my brain the trying to figure out why my plugins were not being deployed as part of my solution between different tenants.

A closer look yielded the answer, that the plugin itself was being deployed but not the messages themselves.

To do this, you need to add in the SDK Processing Steps separately and then deploy your plugin.

blog.PNG

Which really begs the question, when would you ever deploy an empty plugin assembly without the steps you already validated in a test tenant only to now deploy to Production?

A better solution to the above problem would be for the solution window to prompt you, asking if you want to add these already preconfigured messages to your solution (a la dependency components when adding entities).

 

Debugging Dynamics Plugins

Plugins have been around a long time in Dynamics and you either love them or strongly dislike them.

There isn’t much in between.

In working through a few issues on a recent project I had to build a plugin to tap into some many-2-many relationship joins.

If you are looking to solve a similar problem here are some links to get your started.

https://community.dynamics.com/crm/b/mscrmshop/archive/2012/05/14/how-to-trigger-a-plugin-for-many-to-many-relationship

https://community.dynamics.com/crm/b/mylifemicrosoftdynamiccrm/archive/2017/04/09/ms-dynamics-crm-associate-disassociate-message-plugin

In working on this problem I had to do a little more debugging in my plugins and was surprised to see the changes that have come in the Plugin Registration Tool.

To walk through your plugin’s execution, follow these steps.

  • Register your plugin.
  • If you have not already done it, Install the Plugin Profiler from the Plugin Registration Tool.
  • Before going back to Dynamics, Start the Plugin Profiler.

plug

  • Select your profile storage method (I left as recommended).
  • Now validate your code in Dynamics.  Upon completion you will be prompted with a file to download, save it.plug4
  • Now click on the “Replay Plug-In Execution” button at the top of the plugin tool.  The following window will appear where you will associate your downloaded plugin file and plugin.  Also note, that the tool tells you what PID (Process Id) the system is running as which will allow you to attach your Visual Studio process to, to walk through your code.

plug44

When you are ready, click “Start Execution”.

  • When executing you will see output akin to the following (where in my case the name of my plugin is called RecipientHandler.

plug444

This is a much easier, straight-forward and simpler way to debug plugins.  The step-through is great as you can then configure breakpoints in your code to see what Input/Output parameters you are working with and eliminate much of the guesswork.

 

Dynamics Quick Search

The easiest things to do are sometimes the hardest to find.

If you are frustrated with searching for your items in Dynamics via the Entity Search box even after enabling your field for search, you need to do one more step.  Go to your entity, navigate to the quick find view and then selecting the field you want to search on.

From there, you will then be able to search against your entity by the field(s) selected.

search

Easy to miss but easy to fix.

Disabling Quick Create

I ran into an issue the other day where I needed to turn off the usage of Quick Create forms and ensure that the standard forms would always be used for form creation.

The option to do this per entity is relatively simple – Navigate to your entity (via the solution) and uncheck the following entry.

ActivityPointerFail

Not a problem to do per entity, but it would be nice if there was a bulk, non-coding writing way to disable this functionality across all of your entities.  This is a good example of where these features can then be implemented across the board ensuring a consistent user experience.