“No Code” is Not Enough

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.

Advertisements

One Response to “No Code” is Not Enough

  1. I think you’re going in the wrong direction. The goal isn’t to avoid thinking like a developer, it is to make everyone think like developers. Not because we need more developers, or that it’s even useful for users to be developers, but because the development mindset is incredibly useful in a wide range of situations.

    Think security. Code security or application security is fine and useful, but it has far wider reaches than just applications, or even IT. Teaching users to have healthy paranoia so that they are aware of how security impacts everyday life means a more secure work environment in general. It can help them secure their own privacy. It can help them avoid Facebook/Email/Twitter hacks. Take away more of their responsibility and you make them more vulnerable. Teach them how to behave and they’ll be safe in new situations too.

    Backup and code management is useful to help users understand change and reversal of information, not just code. Resource optimization is useful in so many situations, I can’t even begin to make examples, not to mention user experience and design. Heck, teach the average American conditional logic and you’re driving the public debate up into a totally different league.

    If users want to be useful in the future, you need to teach them more, not less, about how modern systems work.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: