Posts in Category: architecture

Don’t Sweat the Customizations

Dynamics365 (and it’s previous incarnations) is designed and built to be customized and integrated into your pre-existing Line of Business applications and/or seamlessly integrate into your new ones.

That’s the goal of the platform (in my humble opinion).

To this extent, the only times you should be afraid of performing customizations on the core or extended system are;

  • You don’t understand the requirements and are changing things willy, nilly all over the place.
  • You have gone beyond writing your own code and are now changing underlying code which may or may not be supported in future upgrades.
  • You are recreating functionality that already exists in the system in your own variant.
  • You are taking something called an account and making it look like a “cat” but then having to create another thing called an “account” because

    Read More


Visual Studio Compatibility

If you’re like me and spend most of your time in Visual Studio, being kicked out to open a Work Item can be an unwelcome window popup and waiting for something to load (that doesn’t need to).

Translation: When I’m in Visual Studio, working in Visual Studio, I don’t need my bugs to open in a browser.

Thankfully this is easy to change.

vs

Read More


Write Automated Code

It doesn’t matter what tool you use for testing your software, the question to you one day will always be the same.

“Can we automate it?”

Can we take you out of the mix and run it on it’s own?

Can we run it across different tenants concurrently with it “crossing the streams”?

Can we send it a 1000x simultaneous requests to see how it does?

Think about the code you’ve written over the last few months – would any of it satisfy these three tests for code that can be automated?

It’s not easy and generally involves an extra amount of testing and development in understanding these scenarios and applying them to your current project set.

But that’s where you shine right?

That’s where you take the tasks that people grind on, you fix them, you automate

Read More


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

Read More


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

Read More