Don’t use your Methodology as a Band-Aid

I can’t remember a time when software development methodology was not a hot, contentious topic of discussion.

“We need to be Agile, because that will make us go faster”

“Scrum will save us from everything we are doing wrong”

“Waterfall is the devil’s child”

“Design Patterns are the only way to go”

“Design Patterns don’t work for me”

The problem with every architecture style and delivery methodology (new and old) is the same as it was yesterday, last year, five years ago and most likely in the 80s.

We refuse to look at what the problem is that we are trying to solve and instead are content with slapping a band-aid on it and calling it “fixed, because we now have #INSERT FAVOURITE METHODOLOGY HERE#”.

If you are not will to identify what is wrong with your delivery of software in the first place, you will never be able to apply the correct methodology that applies to you.

And when I say “identify what is wrong with your delivery of software”, saying “we’re always late” is a cop-out to the true problem.

My company BetaRover Inc, specializes in working with organizations getting over these humps and breaking through the Invisible Barriers that are holding them back.

Check us out, we’re always happy to chat.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dynamics Workflow Registration Mismatch

Recently I was deploying an update to a workflow when I received the following message.

workflowfail

Upon further investigation, the cause of the problem were the dll references I was using for deploying this particular code to this particular environment.

I had updated my Dynamics SDK to use the latest set of dlls (8.2.0.566) while the environment I had already deployed to was on (7.1.0001.3108).  A few updated file references later and I was back in business – coding, registering, deploying and testing my code.

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 you messed up the initial account.

Those are times when customizations in Dynamics can get you into a world of hurt.

Now, think about your work as a C# developer, Java, Web, VB.NET, Python, PHP, whatever and read those 4 items again.

Notice anything?

…..

That’s right, those 4 tenets apply to any software development language or platform not ONLY Dynamics365.

I think the “problem” (if you want to call it a problem with Dynamics) is that Customization and Solution Architecture is a very easy to get up and running with (good) but you can miss a lot if you don’t know what you are doing (bad).  At the end of the day, don’t be afraid to customize and leverage core attributes, do be afraid when you are not leveraging functionality in the system and having to create your own.

It’s not good for you or your customers.

 

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 them, you save time and money and you get back to doing the work that matters right?

Despite all that hubris it is not always that easy and often times it is much harder to convince your Project Lead why you need to understake these tasks for something that might not be requested for another 6 or 12 months.

And this is true.

And the counter to this argument is that if you build it today, that means you can start automating those tests today, you can start updating multiple environments and topologies today, you can start testing against a higher degree of performance thresholds that you are receiving today.

And that’s where the value and the need for this comes from. Because in the moment where you are going to really, really need this type of architecture and design to be in place in your code, you are not going to have the time to wait 2 – 3 weeks for it to be ready.

You don’t have to tackle it all in one fell swoop.

Start small, pick a component that could value most from these capabilities that you are currently work on and build in that functionality. Then over time, keep building in a little more here and a little more there.

And when the day comes that you get asked those three questions, your answer will be –  “Yes, simply turn it on here and you are good to go”.

And that is the answer that every worried Customer Support Technician wants, Stressed Out QA Tester and hopeful Sales Engineer wants to hear to know that your code is ready for the big leagues.

Now let’s go and do it.

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.

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.

 

A Scaled out CRM Solution Architecture

Recently I started work on a pretty big CRM project and I wanted to apply a more scaled out approach to my solution architecture.  CRM offers a great facility to deploy code in their solutions but when starting a new project you should always ask yourself the following questions before you starting adding entities into your solutions.

  1. What is the frequency of updates that will be requested by the users and to what components?
  2. Are there multiple users contributing to this project?
  3. How big do you expect this project to grow by?
  4. What kind of promotional model is in place for deployments?

I  have found that questions such as these generally drive the overall solution architecture I will put in place on a project.  For instance, if we are working with a client that has a Development to Production promotion model with only a developer or two on the project, I’ll suggest deploying as one solution.  However, if the project is quite large, has multiple developers on it coupled with multiple deployment stages (which invariably means a more formalized testing process) I’ll tend to go with a more scaled out architecture.

For this current project I went with a component based solution architecture broken out as follows;

  1. Entities – this contains all my core entities, client extensions and web resources.
  2. Security – this contains all my security roles.
  3. Reports – this contains all my custom reporting files.
  4. Workflows – this contains all custom workflows and plugin functionality.

The reason for this approach is to reduce the load on QA and allow the team to install what they need without fear of interfering with the work of others.

sol

Some scenario examples where this should help the team;

  1. When a developer makes a change to only 1 of the solutions, QA can rest easy deploying that single solution (instead of all 4) and not having to regression test all 4 but only 1 solution.
  2. Reports will most likely be handled by developers that are very familiar with developing custom RDL files, as such, they don’t need references to any of the underlying entities and based on user feedback, they will be able to deploy on their own schedule, outside of the core application.
  3. Having security in it’s own solution now opens this up to being managed by non-developer groups (huge).  Although I don’t recommend deploying an unmanaged solution to Production, this solution can actually start it’s “development” or “work” in a TEST or UAT where Business Analysts can create the security roles they think make sense against the new components built by the developer teams without worrying about interfering with any previous development to date.

These are only a few scenarios where I see this architecture helping out in the long-run.  I have gone through a couple of iterations of scaled out architectures from feature to product based but so far this one represents a consistent approach that can be replicated across projects.

My next step will be to minimize any complexity associated with deploying updates to different environments by writing a little component to deploy the correct solution in the correct order.  However as it stands right now, the solutions themselves are quite loosely coupled and can be deployed without error (i.e., reports) without triggering a solution import error.