⇦ home - lerina - texts - the process
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
andstand-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
⋱⋰⋯