Onja ⋰⋱⋰⋱⋰⋯ (Wave) – A Minimalistic Programming Methodology

Beautiful Code

We ascribe `beauty` to that which is simple,
which has no superfluous parts;
    which exaclty answers its end,
    which stands related to all things,
    which is the mean of all extremes.
    
    _ Ralph Waldo Emerson, _The conduct of life_

Context

This text is inspired by SIMPLE: A Programming Methodology by Tobias Wrigstad, a Professor in Computing Science at Uppsala University.

It also draws from structured programming ideas already in usage back in the 70’s and best exposed by Dolores M. Etter in Problem solving with structured FORTRAN 77 (The Benjamin/Cummings Pub 1984) and Engineering Problem Solving with C.

Problem-Solving process or methodology

Etter stipulates a five point process to solve problems involving the a computer:

The process or methodology for problem solving has the following five steps:

State the problem clearly.
Describe the input and output information.
Work the problem by hand (or with a calculator) for a simple set of data.
Develop a solution and convert it to a computer program.
Test the solution with a variety of data.

source: Dolores M. Etter in Problem solving with structured FORTRAN 77

Key Steps for Problem Solving

Define your problem
Make sure you fully understand the problem
Break the problem down into small and manageable pieces
Go as deep as you can, until you can get to easy (yes or no) questions
Work your way from the bottom until the problem is solved
Recognise some problems are completely out of your control and that’s ok.

source: Problem Solve Like a Computer Programmer | Kyle Smyth | TEDxRPLCentralLibrary

Programming methodology

Wrigstad lays out a Ten Steps system he calls “SIMPLE”

Start with a high-level work breakdown structure
Mine your specification for data (nouns) and actions (verbs – behaviour/functions). Make simple drawings, e.g., mindmaps, to record your insights. Making things look easy is almost always good.
Write code to test the validity of your thinking
…not to drive the thinking! Thinking should invariably come before coding, especially thinking about how you check that your thinking is valid.
Always have a working program
In combination with cheating, this usually means inserting dummy functions.
Compile after every change
Fix errors now, not later. Fix errors one by one. Fix errors in the order they were printed. Take time to actually read the compiler message so you know you are fixing the right thing.
Run the program “all the time” to spot errors
This requires always working code – preferably in combination with automated test that don’t involve ocular inspection, etc.
Recursively break your problems up into smaller sub problems
Only start solving problems when they start feeling easy. Make a task for each problem or subproblem to put on the stack, take tasks from the stack in a reasonable order (preferably easiest first); when the stack is empty – you are done!
Break each task up into increments and start with the easy ones
Generate new tasks to put on the stack as you go. If suitable, start with a straight-line version (without any if-statements). When the straight-line version works add conditionals, one by one. Start with the most basic or the most insteresting cases. When you are writing a loop, do the above steps first and add the looping step last.
Whenever you run the risk of getting stuck, cheat
Don’t forget to push new tasks on the stack that undoes the cheating, later. This records the cheat, which is great.
Use dodging to help breaking complex cases up into several less complex ones
Don’t forget to push new tasks on the stack that undoes the dodge, later. This records the dodge, which is great.
Alternate between thinking, coding and refactoring
- thinking – not so much that you get stuck, though,
- coding – but never without first thinking about what to code, and occasionally
- refactoring – especially to address your cheats and dodges.

[source: SIMPLE _ A Programming Methodology

TDD

There are 5 steps in the TDD flow:

Read, understand, and process the feature or bug request.
Translate the requirement by writing a unit test. The unit test will run and fail as no code is implemented yet.
Write and implement the code that fulfills the requirement. Run all tests and they should pass, if not repeat this step.
Clean up your code by refactoring.
Rinse, lather and repeat.

source: 5 steps of test-driven development

REM: every simgle point of TTD has been turned into a business

… Tools, books and seminars about Group work and software for ticketing, bug tracking …
… Books & seminars about the benefits of tests.
… Tools & seminars about Writing tests.
… Books & seminars about Clean code and refactoring.
… Books & seminars about CI/CD and devops.

REACTO

Repeat: make sure you do understand the problem.
Example: get insights by doing examples
Approach: come up with your approach(es) to the problem (brute force first)
Code: write the code for your chosen approach
Testing: pass the testcases
Optimize: optimize the complexities (time and space) of your algorithm

source: Whiteboard Coding Interviews: A 6 Step Process to Solve Any Problem

Function Design Recipe UofT

Js recipe find it

ALSO of NOTE

How to Solve a Problem in Four Steps: The IDEA Model
Problem-Solving for Developers - A Beginner’s Guide
How to Design Programs, Second Edition
The Program Design Recipe

Introducing The Wave (Onja 〜 ) ⋰⋱⋰⋱⋰

There is no clear cut between programming steps accumulated over time. In real life tend to blend these ways of approaching the actual practice of writing software. Through time these methods and practices have been either made systematic or rendered implicit.

In developing Onja, we took the ancient but still very pertinant 5-points “Problem-Solving with a computer program solution” as exposed by D. M. Etter and the most recent SIMPL Programming Methodology described by Wrigstad.

Dolores M. Etter’s 5 stage process can be can seen as the high-level view of tackling Problems, Opportunities or Challenges (POC). This high-level view can be subdivided into Understanding the Problem and Validate the Solution

Understanding the Problem:

State the problem clearly.
Describe the input and output information.
Work the problem by hand (or with a calculator) for a simple set of data.

Validate the Solution:

Develop a solution and convert it to a computer program.
Test the solution with a variety of data

Wrigstad’s “10 rules” may be seen as the low-level expression of what actually goes through the mind of a programmer as software is written.

I Principles

KISS (keep it small and straightforward). Think Big _ in small steps.
TDD stands for Thinking Driven development
BDD stands for Build Driven deployment

II Precepts

Breakdown Quests or Tasks until there is only one Item per sub-tasks
Validate
- test assumptions and hypothesis
- test your thinking with code
Never stop in a Broken state or build.

III Rules for coding

You can only commit tested working builds
Maintain the flow
- Avoid stoping by temporarly subtituting complicated tasks with a simpler version
- use props and stand-ins until the real think can take over the task
Write your thoughts as comments or pseudo-code

IV Rules for design

Write imperatively first. Then refactor into a functional style.
See thing through three point of views
- Data - Input - Output - processing (Procedural)
- Noun - Verbs - Attributes (Objects)
- Data - Computation - Actions (Fuctional)
Favor push over pull when it comes to Data.
Favor decomposition and composition at all times.

V Keep the tempo

Alternate between::

`thinking` and `validating`
`coding` and `verifying`

Think a little: not so much that you get stuck in analysis paralysis.
Validate a little: Just enough tries or code to validate the thinking.
_ Tobias Wrigstad

The Onja ⋰⋱⋰⋯ distiles these rules and stages into a rythmic wave like software writting process one can condense into _{t.h.i.n.k. a little}⋰^{c.o.d.e. a little}⋱⋰⋯