With no/lo code, the question to ask is what problem is it trying to solve?

If the problem is enabling the citizen developer, there’s definitely a long way to go. The difficulty of the problem can be seen in that there are no citizen electronics designers. Even if you bundle up concepts like a timer circuit (with its transistors, resistors, and diodes, etc.) into an IC (i.e., a 555), you still need to know how to control it and include the surrounding components needed to use its timing capabilities. You can’t just (yet) connect it with other things as if it were lego.

For example, in Electronics All-in-One for Dummies (3rd edition, p91), there is a coin toss circuit. In essence, it flashes two different cooured LEDs, one for each side of the coin, for some period, before stopping on one of the colours. The circuit requires additional resistors and capacitors, in addition to the two LEDs, and a push button in exactly the right location to trigger the circuit. There is simply no way for a citizen designers to know that that’s what’s needed without a strong foundation in electronics.

Now, a solution might be to bundle up bigger circuits like these, but soon you have hundreds and then thousands of circuits in the marketplace and the problem is one of finding the one you want. Then, if you only find one that’s close, but not exact, you have the problem of how to modify that circuit to meet your needs. For example, what if you had a three-sided coin? Or wanted to extend it to 6, or 12 or 20 for different sided dice? Without that strong knowledge, the citizen designer has no chance.

If the problem is faster development for developers, a fundamentally important problem remains: What exactly do you want me to build? Just because you can build something quickly, doesn’t mean you’re building the right thing.

If you’re building something simple, then you can probably get away with the inevitable iteration that comes from a ‘build it and test it to see if it’s right’ approach. If it’s something complex, like core banking, then it’s not feasible to build it in this way.

Returning to the citizen developer, if we do have a decent no/lo code tool, and it has a rich marketplace, then we can solve part of the problem. If the citizen can describe what they want with sufficient clarity, then they may surface a module that does much of what they want. However, as with the electronics analogy, if the citizen developer wants to modify the module in some way, they will need a strong background in programming and application architecture in order to unpick, modify, and restitch-up the module in the way they want. I’m sure you’ll agree that this is a tall order without that knowledge.

The problem is actually with the requirements

What we need is to take a different approach to solving the problem of fast (and right) development. We can either focus on the building tools, or on the requirements capture tools.

The problem remains in software engineering that it is the only one of the five main disciplines that does not have a universally agreed process and visual blueprint for its products. In the absence of a visual blueprint, we have to rely on written requirements. But, ask yourself: Have you ever heard an engineer say ‘Absolutely! A thousand words is way better than a picture.’?

So, the real problem, in my view, is in the requirements. The solution is probably along the path of executable requirements. But I don’t mean code generation. We all know that it, at least at the moment, is rife with problems. I mean code deployment.

I’m working on a project with the express goal to solve the executable requirements problem. I’m not necessarily aiming it at the citizen developer, but more the intermediary people, including business analysts, business architects and UI designers. People in these roles generally have the necessary structured thinking to think through and design complex applications. The next step will be to make it relevant for the citizen developer.

If you’re interested in having a chat, reach out here: https://www.linkedin.com/in/cr..., or email me: craig.errey[at]solvegroup[dot]com[dot]au

The requirements problem
The most common approach to documenting requirements is the written word, usually in the form of user stories (see NaPiRE http://www.re-survey.org/#/hom... for example). This fact makes software engineering an outlier.

Software engineering is the only one of the five major engineering disciplines that does not have a universal process and visual blueprint for its products. Civil engineering has its architectural blueprints, mechanical has its design drawings, chemical has its molecular diagrams and processes, and electronics has its circuit diagrams and PCB layouts.

In the absence of the visual blueprint, we have to rely on the written word. But have you ever heard an engineer say 'a thousand words is better than a picture'?

What about UML? It's visual.
Sure. The written requirements can be converted into UML, often important for large, complex applications. However, these diagrams are rarely readable, understandable and verifiable by the business or the end user. It's very hard to relate the user stories with their multiplicity of concepts and relationships to the discrete diagrams.

There are other challenges with UML. While there are 15 standard diagrams, the user interface is not one of them. Yet the UI is just about the only thing people can use to tell if what you've designed for them is what they want.

Another challenge is that UML doesn't help if your preference is to buy your solution. I've never seen anyone hand over a bunch of UML diagrams to a vendor as their statement of requirements. It is, almost always, a huge litany of written micro requirements that the vendor invariably says 'compliant' to.

There clearly needs to be a visual requirements modelling approach that does the same job as the architect's drawings before they're handed over to the structural engineers for detailed specification.

Even if we had an architect-like set of visual models for software engineering, do people even know what they want?
Conventional wisdom says no. People don't k now what they want until you show them. You need to build something, let them use it, then iterate towards the desired solution. And besides, they keep changing their minds so clearly they never knew what they wanted in the first place.

However, if we constrain ourselves to enterprise applications for the moment, then let's start with question: Do people (generally) know what their job is and how to do it? Hold back on your initial response! People are often not doing what they're required to do due to lack of role clarity, variable management, inappropriate culture and so on.

But let's assume that people do know what they're supposed to do. What people want, therefore, is simply to get their job done. When BAs and devs and similar say people don't know what they want, it's like saying people don't know what their job is. It's simply not true. It often stems from asking the end users question 'What do you want the app to do?' instead of 'What's your job and how do you do it?'

The starting point for requirements for enterprise applications should be the job descriptions of the people who will use the app. There are many techniques from organisational psychology to greatly improve the quality (comprehensiveness, structure and detail) of the job description, elevating it from a list of micro-managed tasks.

What next?
We need to examine the fundamentals of software engineering. Why is it the only one without a visual blueprint? Is software engineering really so different from all the others? Are requirements really unknowable and therefore 'emergent'?

The issue is not agile vs waterfall, nor buy vs. build, nor the quality of PMs, devs, BAs, management or fickle end users. The problem is reliance on the written word and its inherent ambiguity that separates software engineering from all other engineering disciplines. This is the problem that needs to be solved first. The other disciplines all enjoy extremely high success rates, even when tackling something as gnarly as the Wendelstein 7-X.