Logic Makes the Software Turn Around
Radical Object-Orientation 101
Logic is a term strangely missing from many discussions about clean code development or software architecture. Yet it is such an import concept because without it many a heated argument about principles and structures does not make sense.
By logic I mean the basic code you learn to write when you start programming. Here's an excerpt from the textbook on Pascal which kicked it all off for me in 1980:
What you see here is pure logic:
control statements, in this case REPEAT-UNTIL for a loop. Other statements are if-else, switch-case, while, for, foreach... or what your programming language is offering you in the same vein.
I/O or more generally "API-calls", i.e. calls to libraries you choose to base your code on. The most important characteristic of these function calls like WRITELN() is that you don't have control over their source code. For all practical matters they are black boxes you're using as is.
transformations which range from mathematical operators to string operations or URL helper functions.
Logic is what creates software behavior: functionality, performance, security, usability etc. It constitutes the gears in your software, hopefully fits neatly together, and turns without friction at runtime.
Software behavior is what users observe and want to be useful for their purposes: some input is transformed into some output, maybe by considering some state. Software always has been and will be about IPO: input-process-output. And logic is what accomplishes that feat.
Hence, the only thing users want is programmers to produce appropriate logic. All else, like comments or whitespace or constant/variable declarations or function definitions or classes... they don't want. Or at least don't care about.
Here's another excerpt from the Pascal book:
What's of concern to users (or any stakeholder except you as a programmer) is only the highlighted part of the code. That's where behavior is created, that's where processing actually happens at runtime.
What about the rest of the code? Why does that exist at all? Well... it seems necessary for other reasons than behavior creation.
And these other reasons are what clean code development is concerned about.
Logic alone is not enough. Writing just any logic in any way to deliver requested behavior is not enough. It might be sufficient in very small scenarios and when taking the first steps in programming. But very quickly the amount of logic needs to grow beyond what a single human, let alone a team can handle without help.
That's when principles and concepts are needed on how to structure logic with functions and modules (e.g. classes, libraries). That's the hour of software architecture and clean code development.
The first and foremost task of software developers is to compose code from logic building blocks in a way that it performs as required, i.e. shows useful behavior. It's like a chef's first and foremost task is to compose a tasty meal from available ingredients.
But sooner than later it turns out, that's not enough. Because if a chef just focusses on cooking, the kitchen soon will be a mess and fridge and larder will be empty. Likewise too much focus on just logic will be detrimental to the longterm productivity of a software developer.
Without understanding what logic is and that its growth in size and complexity under constant pressure from stakeholders to adapt to yet more requirements is creating problems beyond the how of behavior, clean code development does not make sense. That's why I wanted to at least once explain this core term explicitly.
For more context see my blog on Radical Object-Orientation:
