Programming something from scratch is a very labour-intensive process, requiring skills which are very much in-demand. Fundamentally, it remains a hugely expensive way to create something.
Programming often feels a bit like having to build a model of Notre Dame cathedral from matchsticks. You might have a clear view of the beautiful thing you want to create, but the means at your disposal entails that the process will be slow and fragile.
No Code pros and cons
It should be clear then that No Code is not just, or even mostly, “for non-programmers”. No Code can be a way to create software more quickly, more cheaply and more robustly. No Code can be a primary route to improved programmer productivity.
What is the downside of taking a No Code approach? The downside is usually considered to be reduced expressiveness. If you don’t have the full freedom of a programming language, it can feel a bit like building a Notre Dame model with bigger blocks than matchsticks: you can build the cathedral more quickly and easily, but you can’t portray the gargoyles in loving detail. Its a trade-off.
But some No Code environments are more expressive than others, and we think there are circumstances in which No Code is in fact not a trade-off at all, but instead simply the best way to create certain software. One such circumstance is the kind of clinical decision support tools we have been involved with: tools embodying knowledge of expert clinicians to help health workers in low-resource settings faithfully follow complex guidelines.
Let us portray the task: suppose that you need to build a medical diagnosis and treatment system which should help people follow clinical guidelines and best practises when treating a sick child. And suppose there is a medical doctor who has the specialist knowledge on which the app should be based. What would this software development process look like?
The Doctor and The Programmer — a validation gap opens
Normal programming methodologies, would lead us to assume the existence of at least two people: the Doctor and the Programmer, and we assume the Doctor somehow conveys her knowledge, which the Programmer then codes.
In this scenario, we imagine the Doctor conveying her knowledge by writing a document sufficiently formal — precise, without any vagueness, unambiguous, etc. — that it can be used to program.
There is already a challenge here which is not our main concern here, so we will just pose it without addressing it: which specification language can/should the doctor use for this?
Suppose the Programmer received the logic from the Doctor in a suitable form and completed the implementation task. Since we are assuming the Doctor herself cannot program, the code produced by this methodology will not be intelligible or transparent to her, and will be a black box. She will not be able to validate the correctness of the implementation by reading the code.
But how then can the correctness of the implementation be judged? How can we be sure the Programmer has not misunderstood the Doctor’s intended meaning on certain occasions?
Can we do this by testing the resulting app? The problem here is: if we are dealing with complex clinical guidelines, with a lot of conditional logic dependent on many variables — symptoms, test measurements, medical history, etc — we will most likely be dealing with a situation in which combinatorial explosion entails that it is simply infeasible to validate the correctness by “testing” — the number of possible paths through the logic will be too great.
One can understand the rules of chess without being able to state all possible moves. In the same sense, what we need is for the Doctor to be able to check her “rules”, rather than us check all possible paths which result from them.
At even a surprisingly low level of complexity, combinatorics kicks in and validating the correctness of such a black box becomes a huge project challenge. The challenge is even greater when you accept that, later on, such guidelines and best practice recommendations may well be subject to frequent change (which means the validation question is subject to frequent re-opening as changes are made).
We think the traditional software development approach taken here is wrong from the start, because it entails an unbridgeable divide between the Doctor and the implemented logic — the fact that the logic the app will embody ex hypothesi cannot be intelligible to her is a validation gap which is very difficult or impossible to close.
No Code approach eliminates the validation gap
A No Code approach is the situation in which there is the Doctor, but no Programmer needed. The Doctor does not represent the logic first in some document which could be subject to misinterpretation, instead she is given a tool — a No Code environment — within which she directly transcribes the logic she wants to see advised.
This task cannot but be complex since the domain is complex, but doctors are trained to deal with complexity, and it may be less complex than the challenge specifying desired logic in a document (because the No Code environment, by its formal nature, permits no vagueness and can give all kinds of automatic support in ensuring that the logic created avoids contradictions, or circularities, or paths which don’t yield any benefit for the user).
The important thing is that the Doctor’s task is not, and must not be, coding. It must be a computer-assisted specification process which the Doctor finds intelligible and transparent and which results in something — formalised logic of care - that she can also easily update when the guidelines change. The process has to be done at a very high largely declarative level where the Doctor can be fully concerned with representing her clinical expertise and not be distracted by “computing” issues.
Most importantly, for the sake of correctness, the logic she defines in this way has to be the logic actually executed within the app, without any further Programmer intervention required in order to make that the case.
Program = Specification
Taking such a No Code approach is not a final answer to the problem of ensuring correctness relative to the specification, and of course there is an obligation to exploit all testing means too, but given that the specification is now the implemented logic itself, transparent to, and under the control of, the Doctor we eliminate the validation gap entirely, and take a huge step forwards.
We do not see how, in this kind of circumstance (and we believe the same is true for other fields such as law) a traditional coding methodology can be a better approach than such a No Code approach. In this circumstance, No Code is not merely a more efficient but cruder cousin of the traditional approach, it is in fact superior.
We end with reflection of an experienced clinician, Dr. Douglas Watson, experienced also in the use of the Logiak No Code environment, who describes an additional reason why this approach is the best for the case of medical diagnosis and treatment applications:
Clinical guidelines cannot easily be translated into precise logical statements. Guidelines are way-points between which the trained and experienced clinician maneuvers. In contrast, software has to be fully-defined, discrete and unambiguous.
In clinical practice, judgments must be made: there are subtleties and gaps in guidelines that can only be identified and resolved by a knowledgeable clinician. For all but the simplest logic, without a No Code environment, this would entail an almost interminable series of iterations of understanding between doctor and programmer.
In contrast, with a supportive No Code environment, clinicians are able to perceive and resolve the ambiguities and gaps in the very process of formalising guidelines, algorithms, and practical knowledge into logic, which grants a better hold on the coherence and completeness of the consultation than interminable iterations with a programmer would allow.