I’m very, very tired of seeing/hearing the phrase “no code”. I see presentations advocating “no code” solutions for SharePoint. I see advertisements from companies who proudly declare that they’re all about “no code” apps. The issue isn’t confined to the world of workflow, but I see it arise in workflow-land readily and frequently.
It’s not that eliminating code isn’t a useful thing — it is — but when authors/speakers lead with the phrase “no code”, it suggests that they’ve likely missed the point. To wit:
“No code” doesn’t really help users.
The implication of “no code” is that it’s easier, and that “even users can do it”. Well, “no code” does not always mean “easy”, let alone user-accessible.
Take SharePoint Designer, for instance. Users aren’t being done any favors if they still have to do things like increment counters, check flags and semaphores, initialize variables, stage a set of dictionaries in order to call a web service and parse the results afterwards, or poll for results. Actually, add calling web services to that list.
People who think like developers and DBAs see value in data models, but users just see content (documents, lists, images, etc.). They need to know what they’re working with, not see it abstracted into generic objects.
Other offerings may look friendly at first glance, but every drag, drop, configuration choice, and term in the user interface belies a developer mindset bias.
Still other offerings all but require the user to learn a new language to get anything done; it may be a visual/graphical language, so it qualifies as “no code”, but it’s still complex and hard to follow without training. For example, to get a manager to even understand a process model authored in Business Process Modeling Notation, you need to teach her how to read BPMN. To get a business user to author BPMN, you need to teach him a whole new discipline.
“No code” doesn’t really help IT.
“Citizen Development”, as Gartner puts it, has immense potential. But ask many IT professionals what they think of all those elaborate Excel, Access, InfoPath, and SharePoint Designer solutions and you’ll very likely get an earful of complaints.
Just locating and keeping track of those no-code solutions is difficult enough. Monitoring bad behavior (e.g., runaway loops, excessive network and database I/O, etc.) gets tricky. Understanding what is affected when a no-code solution is changed/deleted is hard. Figuring out who will maintain existing no-code solutions when the author leaves the company can get nasty, let alone the odds of the new no-code developer being able to understand what the previous person did.
Recent developments in Microsoft’s approach to business intelligence excepted, all too often, “no code” means “no responsibility”.
“No code” gives an impression that code is bad.
Believe it or not, sometimes code is actually pretty attractive. Why? Code can be versioned. Code can be profiled. Code can be validated. Code can be optimized. Once you have to think a developer’s thoughts, you should at least have tools equal to the task.
It’s not about “no code” — it’s about user focus.
Many of us want users to have the ability to build some solutions for themselves. Many organizations need this if they’re to get past backlogs and bottlenecks. If that’s to be the case, users should see concepts they find familiar. Or at least not entirely unfamiliar. Put another way:
Not having to code like a developer is not enough.
Not having to think like a developer is the goal.
“Power users” shouldn’t have to denote users who can act like developers, but rather users who can understand a business problem, the content, the process, and the logic needed to make something happen. They deserve tools that reward that thinking. Those tools should be governable and extensible, too — without getting in the way.
If all you think you need to do is free them from coding, you’re going to have to do better than that.