But, with all that, I absolutely hate when somebody calls me a Dynamics developer. That I’m formally on the team that’s doing “development” does not make me a developer. In my mind, I’m a Dynamics Consultant, and, so, I can pick and choose the tools which fit best in every particular situation. Sometimes, it can be a workflow. Sometimes, it can be a plugin. And, quite frankly, I don’t care that much about what the Architect (if there is one on the project) is going to tell me since, more likely than not, we will have to discuss our options once I look into it anyway (but that’s why I prefer to be the Architect.. rather than to give that much authority to somebody else)
So.. This post is going to be much less technical than most of the other posts here, and, actually, it has a lot to do with the discussion Ben Hosking started recently:
The problem is right there..
Apparently, somehow there is a separation between “consultants” and “developers”. But, where I would agree that not every developer is, also, a Dynamics Consultant, I would really disagree with anyone telling me that you can be a Dynamics Consultant without knowing anything about the XRM capabilities.
However, if you know about those capabilities, you’ll be able to make a conscious choice when asked about the most appropriate technique to use in each particular situation. That’s, basically, what makes you a Dynamics Consultant – your ability to advise the client what the options are. Of course, you might not be that strong on the technical side to develop a plugin from scratch.. But, as long as you understand the options, and as long as you can explain them to the client, you are a consultant.
So, getting back to that screenshot above, I do think that Dynamics Consultants are supposed to be able to choose which technique is best, and that includes development techniques as well. Some consultants might be better developers than others, but it does not mean that any consultant can completely ignore the “development” side of Dynamics.
The reason I hate being called a Dynamics developer is that it sort of pushes me into the corner. Developers are supposed to develop, that’s not my case at all. There is so much more I’m supposed to do on the Dynamics projects – business analysis, solution design, software architecture, pure coding, users training, pure configuration, maintaining the server, opening support tickets with Microsoft, maintaining the backlog, providing support to the users.. this list can go on and on.
This so-called “Dynamics developer” role is really quite peculiar and there is so little difference there is from a consultant. If you are a .NET developer, your work is focused on the development. But, if you are a Dynamics developer, you have to understand the product first of all – otherwise, your opportunity plugins will be conflicting with the out of the box price calculations, your validation plugins will be missing some unusual scenarios, and so on. Once you get there, you suddenly become a consultant, and, at some point, you will find yourself saying “well, I think it should be done with a workflow.. or, wait, it would be even easier to just configure a parental relationship.. although, how about this OOB workaround?”. But, when it’s called a “developer” role, that sort of implies certain things about what the person is supposed to be doing, and this is where things can easily go wrong because of the incorrect expectations on both the client and the “developer” sides.
So, call me all you want, but don’t call me a developer.. despite all the development I do every day. Dynamics Consultant would be just fine by me, although, if it’s a Dynamics Solution Architect, it’s, probably, even better.. since that gives me a bit more “authority” in terms of making decisions.