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.
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.
- 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.
- Susan can use a company-approved “citizen development” platform and build and maintain the resource herself, without complication, without coding, and without delay.
- (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?)
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.
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.
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.