In Praise Of Code and No-Code

Two weeks ago Neil Benson wrote an excellent article on LinkedIn, as a response to a claim that everyone working as a functional consultant in a Dynamics 365 project team should also know how to write code. This really resonated with me and I shared the article, along with a bit of commentary of my own. My post, in turn, started to gain quite a lot of traction on the LinkedIn feed. It looks like we had touched upon a topic of great interest within the network of CRM professionals.

If you read my post above, it pretty much summarizes the main points I wish to bring out in this discussion:

1. There is much more to ensuring Dynamics 365 project success than being able to do hands-on software development.
2. A big chunk of the value delivered by Microsoft’s cloud platform is not relying on custom code development.
3. The remaining chunk that is custom code driven work should be left to professional developers and not copy-paste heroes.

There have been some very good arguments written in the comments section of the LinkedIn post, so I urge you to also view them for gaining greater perspective on the topic. I see a lot of resemblance with the “should designers code” meme in the original assumption that functional consultants would be able to do their jobs better if they also were familiar with developing custom code. Much of what has been said in the heat of that debate between coders and non-coders probably applies here, too:

Alan Cooper’s four part article covers the dilemmas in general software development teams with such great insights and depth that I won’t even attempt to dive in the same direction here. In practical terms of a CRM project, when it comes to the availability of skills and experience needed in carrying out the wide range of tasks during the project’s lifecycle, the manager in charge of resources is always going to need to do some juggling. The less you ask the team members to juggle between completely different kinds tasks, the more likely they’ll able to focus on actual customer value generating activities rather than keeping all the balls in the air simultaneously. Here’s how Neil Benson put it:

“Asking a functional consultant, with no formal computer science education or experience as a professional coder, to find and copy someone else’s JScript from Stackoverflow and paste it into your Dynamics solution is asking for trouble.”

I don’t touch code myself but I do try to get my hands dirty on a wide variety of technologies. For example, today I spent a few hours getting familiar with Azure Service Bus, testing how without writing a single line of code I was able to push plugin execution context data into a cloud based message queue and work with it via a GUI in Azure Logic Apps. Now, I would never recommend myself as a person you should hire to set up your production ESB, but I do feel like I need to have a deeper understanding of these technologies than I could gain just by watching through the flashy demos in Microsoft keynotes. Seeing the different sides and reading/hearing what those with deep expertise on a particular technology have to say about it, that is essential. Going and actually trying to step into the shoes of an expert for that technology – probably an unnecessary detour.

Skimming the bits from the top without diving deep into the dirty details of writing real code might sound like being afraid of all the complexity that awaits beneath the surface. However, the lack of code in a solution doesn’t mean that the complexity of the solution couldn’t be high. The CRM Tip Of The Day post “The story of the small change” perfectly illustrates the way in which individual configuration items built entirely via the graphical tools provided by MS can have dependencies that require you to have a rigorous testing process in place. It’s not just the changes of a system either, since you can easily use workflows and business rules to build a level of complexity into your business logic that doesn’t reveal itself in the test scenarios the consultant behind the design might have thought of. Whether you’re delivering the end product via code or configuration, bugs will sneak in there and eat away a part of your life – be it before or after production deployment.

The argument for doing things via point’n’click configuration “because it’s so much faster to build” shouldn’t be the one and only argument. Yes, it is often much, much faster to put together the first iteration of a solution via graphical tools. This in itself can be a huge value for the business because you can validate the proposed solution quickly with the relevant stakeholders. Often you’ll only get to the actual requirements when demonstrating live parts of what the initial requirements said. Now, the main reason why Real Developers are often afraid of what “citizen developers” might come up with when given quick tools for building no-code apps is that they may lack the experience of seeing the full lifecycle of a business application. They’ll mistake the first PoC as being equivalent to the final production solution, with little thought given to the work that still remains ahead. This experience isn’t something you must necessarily gain via writing code yourself – a no-code functional consultant just needs to gain sufficient exposure to the various stages of the process via working as a part of the CRM project delivery team.

I think we all need to be able to see “beyond code” when building solutions on top of platforms like Dynamics 365 Customer Engagement. Going full-on no-code in your design approach is probably going to unnecessarily limit the value that could be gained from an extensible application platform, forcing you to unsustainable workarounds and resulting in poor UX for the system end users. At the other end of the spectrum, always resorting to your custom built components before having a thorough analysis of the configuration capabilities and complementary cloud services found within your ecosystem of choice will likely increase the solution’s TCO and put the long term reliability of your complex business application at risk as changes in related processes, personnel and technologies occur over time.

Please feel free to leave comments on how you see the role of code & no-code work evolving in Dynamics 365 projects.