Citizen Development - It’s Everywhere, Unstoppable, And Good - Part II

By Mike Fitzmaurice


If It Looks Too Much Like Programming, You’re Doing It Wrong

Software tools that empower employees to create and automate workflows should be easy to use. Plain and simple: They are not programming utilities. And they should not look like programming utilities.

Those tools should be powerful, yes, and comprehensive. They need to have essential functionality, of course, and be able to integrate with other applications that workers use every day. That’s a given. But they should not be based on languages that developers use, like JavaScript, Python, or C#. They shouldn’t be streamlined versions of Visual Studio or Eclipse. And for heaven’s sake, they shouldn’t require a developer’s mindset to learn and use.

Take the common exercise: Ordinary line-of-business employees, like Susan, want to build and maintain simple websites for internal use, such as wikis, file shares, forms, workflow, or documentation sites. Susan has three choices.

  1. She can submit a ticket for the IT department — and that means drawing up requirements, finding a budget line, and submitting to the IT department’s wait time and internal processes, including sign-offs.
  2. Susan can use a company-approved “citizen development” platform and build and maintain the resource herself, without complication, without coding, and without delay.
  3. Susan can take courses in C# and SharePoint APIs, or become an HTML/JavaScript programmer, and once she’s completed the courses, look to building her solution.
  4. (There’s actually another choice: Susan can go rogue, download something from the internet or find a free cloud-based resource. This is common and always is bad news for many reasons, including the lack of security, so let’s discourage that, okay?)

As you would expect, I’m a huge proponent of the second option. Yet too often I’ve seen blogs that push the third option – insisting that employees need to use C# or JavaScript or SharePoint to build workflows. Ummmmmm – no.

If we let Susan create her own solution using easy-to-use, non-developer tools, and solve her own problem, there are so many benefits. It will be done more quickly. It will be done more accurately, since it’s created 100% by the person closest to the problem — and who truly understands the desired outcome. It can be changed at a moment’s notice when a better solution presents itself or if conditions change. It’s less expensive. And it doesn’t require expensive IT resources.

A nice benefit occurs when Susan can solve her own problems and improve efficiency with workflow technology: She becomes a guru. And she can help others solve their problems and improve efficiency with technology too.

Remember the Early Spreadsheet Experts

Think back to the early days of spreadsheets. Remember Lotus 1-2-3, Microsoft Multiplan, and then Microsoft Excel? Nearly any employee could use the spreadsheet software to solve very simple problems — but a few employees went beyond it. They explored complex formulas and functions. They linked to budget roll-up spreadsheets and pulled data from other external sources. They wrote macros. They became citizen developers. And they solved many, many business problems without using any IT resources.

What made those gurus successful is that 1-2-3 and Excel weren’t designed for programmers. In fact, programmers scoffed at 1-2-3 formulas and Excel macros.

Spreadsheets were designed for budget analysts, department heads, and administrative assistants — many of whom went on to become technology consultants, based on a valuable combination of software expertise and deep knowledge of specific business domains.

Remember back to those early tools, and even the current iterations of Excel. While there is a programming language of sorts, it’s quite simplistic, and lacks many of the core features you’d find in JavaScript, C#, PHP, and so-on. Spreadsheet macro languages, like those of most workflow automation tools, are completely goal-oriented.

They’re also relatively safe. The goal-orientation reduces some options, to be sure, but it also reduces risk. Let’s not even call working with these things “development”. Let’s call it “solution building”.

It’s Not Only the Language

The tools used by professional programmers are designed for… well… professional programmers.

Architecture and design tools. Code libraries and APIs. Coding tools that highlight keywords and offer autocomplete. Static analysis tools. Run-time analysis tools. Security analyzers. Debuggers. Resource profilers. Memory leak detectors. Performance emulators and load testers. Those are bread and butter to a coder, but might as well be ancient Sanskrit to Bob, a retail administrative assistant who is trying to simplify the process of gathering daily sales reports and turn them into information to help his manager make rapid decisions.

If you make citizen development tools look like programming tools, you won’t have citizen development.

What’s more, if citizen development requires the sort of methodologies and practices used in software development departments, the whole exercise will crash and burn. Code reviews, scrum development, two-week sprints, code repositories? There are “citizen development” tools that support all of that. But the only people that will benefit from “low-code/no-code development” are professional developers. They can save time over coding, but they’re still doing real development.

The emphasis, however, should be on helping the worker — Susan, Bob, or whomever — automate their tasks. After all, automating workflows probably isn’t even in their job description. It’s something they’re doing to make their job easier, and help some part of the organization function more efficiently and more effectively.

Mind you, if a solution-builder toolset has facilities to catalog, back up, and document employee-written workflow automations, that’s great. But they should be simple to use, and if possible, purely automatic in their functionality.

Amateurs Writing Code? No Way!

We’ve been talking about one big reason for keeping citizen development tools simple: To make sure they get used to solve business problems. Another reason is that the more citizen development resembles software development, the more antsy the IT department becomes. “Amateurs writing software? Unacceptable!!” You get that possibly from politics, but mostly because non-professionals can do a lot of damage when they right bad code.

Amateurs writing code is scary. Indeed, no way. But amateurs assembling solutions isn’t scary at all.

Don’t even think of citizen development as development. Maybe we should get rid of that D-word, because it scares the crap out of software engineers.

Solution building, especially workflow automation problem-solving, is more akin to playing with blocks. Assembling workflows out of Lego bricks. Some bricks represent data, others are actions like assigning tasks or sending notifications. Others are describing what activity to watch for so we can react to it automatically. That’s not programming, is it? Solutions should look more like Lego projects, and less like source code. And there are a lot of tools that work that way.

Don’t make your smart, solutions-oriented employees learn JavaScript or code frameworks.

Save that for the IT staff who are solving enterprise-scale solutions. Don’t push them to become programmers, because that’s not what they are. Acquire good building blocks and provide them. Have your own development resources construct the ones you want to make sure they have.

They’re ordinary employees, who want to improve efficiency and seize opportunities. Help them. Make it easy. It’s the best way to go.


Read Part I


About Mike Fitzmaurice

Mike Fitzmaurice is the Vice President of Workflow Technology for Nintex, the world leader in workflow and content automation, and is its subject matter expert and chief spokesperson for workflow, business transformation, and technology matters.

More About Mike