Low Code Development – What is It?

You are confusing documentation with specification.

Specification is the process (usually collaborative) through which the definition of what the format should do and how a hypothetical application should handle it, render it, or parse it.

It's a design process like the one W3C does when creating the HTML or CSS specifications way before browsers implement it.

Or course the product of this process can be understood as "documentation", but it's not the documentation of an application.

If you are creating a new file format, discuss and design the specification.

Then code the application that uses that file format ( or have others code it ).

But to create a new file format you don't have to write a single line of code. The specification may never be implemented, yet it exists as an specification.

Obviously when an specification does get implemented, it is revised and extended with the feedback of implementers.

The premise of the question is, frankly, astounding. We suppose that there is a large change to fragile, complex code, and that there is simply not enough time to review it properly. This is the very last code you should be spending less time on reviewing! This question indicates that you have structural problems not only in your code itself, but in your methodology of managing change.

So how to deal with this situation? Start by not getting into it in the first place:

• Identify sources of complexity, and apply careful, heavily reviewed, correct refactorings to increase the level of abstraction. The code should be understandable by a fresh-out-of-college new employee who knows something about your business domain.

• Identify sources of fragility; this could be by review of the code itself, by examining the history of bug fixes to the code, and so on. Determine which subsystems are fragile and make them more robust. Add debugging logic. Add assertions. Create a slow but obviously correct implementation of the same algorithm and in your debug build, run both and verify that they agree. In your debug build, cause rare situations to occur more frequently. (For example, make a memory allocator that always moves a block on reallocation, or always allocates a block at the end of a page, or whatever.) Make the code robust in the face of changes to its context. Now you don't have fragile code anymore; now you have code that finds the bugs, rather than causes the bugs.

• Write a suite of automated tests. Obviously.

• Don't make broad changes. Make a series of small, targeted changes, each of which can be seen to be correct.

But fundamentally, your scenario is "we have dug ourselves into a hole of technical debt and each complex, unreviewed change digs us deeper; what should we do?". What do you do when you find yourself in that hole? Stop digging. If you have so much debt that you are unable to do basic tasks like reviewing each other's code then you need to stop making more debt and spend time paying it off.