Styles of development

The process by which we go from git init to pdflatex paper.tex

We will cover some useful methods and styles for different situations

This is based on my experience
depending on the case - what fits better might be different!

Styles of development

Iterative design
Iterative and incremental development
Test-driven development
V-model
Software prototyping
Continuous deployment
Scrum
Waterfall-model
Agile
Lean
...

This is too much in my opinion

Styles of development

Building up novel components

Iterative and incremental development
Software prototyping

Building up well-known components

Test-driven development

Maintaining code

Kanban, issues, sprints

The fallback style

The "None" pattern - just do it

Styles of development

Iterative and incremental development
Software prototyping

I have modified these to fit better what scientist usually do

(if you want to read the "enterprise" versions - have a look in the handouts or search online)

Styles of development

Iterative and incremental development
Software prototyping

Define the goal and some way to validate it
Imagine a fuzzy high level design
Choose a sub-component
Think up an implementation and a validation method
Iterate until it works
Goto (3.) until you have a working prototype
Goto (1.) and re-evaluate until you reach the goal

Done

Styles of development

Iterative and incremental development
Software prototyping

This is probably close to what you already do!

Styles of development

An example:

Goal: A new integrator
Validation: better accuracy than Euler (plot)
High level design:
Different methods run in the same way
Save output (for quantitative), different target equations
Plotting (for qualitative)
Sub-component: The Euler method
Plan: Just a function that take step-size and number of steps
hard-code an equation that has analytic solution
Iterate until it works

So back to choosing a sub-component

Styles of development

An example:

Goal: A new integrator
Validation: better accuracy than Euler (plot)
High level design:
Different methods run in the same way
Save output (for quantitative), different target equations
Plotting (for qualitative)
Sub-component: Arbitrary equations
Plan: Make Euler method take in target equation name
make library of equations
Iterate until it works

Keep going until I have a first prototype

Styles of development

An example:

I might discover once I have that prototype that

The method abstraction makes the integrator too slow
Need to sweep equation parameters
hard coded equation library will not work
So I re-evaluate the goal and refactor

Does this sound familiar?

Styles of development

A few adjustments along the way

Be aware of the process you use to develop
(Then you can make adjustments and improve it)
When a sub-component works:
transfer your validation into a test
(then you don't have to worry about introducing computational bugs!)
A computational bug is miles worse than a runtime bug
"Huh, I wonder why my energy is always 1% off what's expected"
Or transfer you validation into an usage example

Styles of development

Iterative and incremental development
Software prototyping

Adapt to your needs and scope

If the project is small:
just design it up front in one go and iterate that
If the project is huge:
make a stricter plan so it does not descend into chaos
If the components are not vital:
skip the tests - if they break, they break
If you don't need more than a prototype:
skip the refactor / re-evaluate stage

Styles of development

Building up novel components

Iterative and incremental development
Software prototyping

Building up well-known components

Test-driven development

Maintaining code

Kanban, issues, sprints

The fallback style

The "None" pattern - just do it

Styles of development

Test-driven development

Define the goal
Define the needed behaviour of a component
Write tests for that behaviour
Write simplest implementation to make test pass
Refactor code while ensuring tests pass
Goto (2.) until you reach the goal

Done

Styles of development

Test-driven development

An example:

                    
                    class TestAnomalies(unittest.TestCase):
                        def test_true_to_eccentric_hand_calc(self):
                            e = np.linspace(0.1, 0.9, num=100)
                            # For E = pi/2 hand calc and Pythagoras gives 
                            # `\\nu = \pi - tan^{-1}(\sqrt{e^{-2} - 1})`.
                            nu = np.pi - np.arctan(np.sqrt(1.0/e**2 - 1.0))
                            E0 = np.ones(e.shape)*np.pi*0.5
                            E = kep.true_to_eccentric(nu, e)
                            nt.assert_array_almost_equal(E, E0, decimal=7)

                        def test_eccentric_true_inverse(self):
                            nu0 = 1.2345
                            e = 0.5
                            nu = kep.eccentric_to_true(kep.true_to_eccentric(nu0, e), e)
                            self.assertAlmostEqual(nu0, nu)

Then I would work on the true_to_eccentric function

Styles of development

Test-driven development

An example:

Dangerous if you do not know everything you need to test up front
Prevents pre-mature bloat: don't write it if it is not there to make the tests pass
Ensures the implementation functions immediately

Styles of development

Building up novel components

Iterative and incremental development
Software prototyping

Building up well-known components

Test-driven development

Maintaining code

Kanban, issues, sprints

The fallback style

The "None" pattern - just do it

Styles of development

Kanban, issues, sprints

Kanban & issues

Nice for distributing work across a team over time
(e.g. github issues -> todo list)

Styles of development

Kanban, issues, sprints

Sprint

From what I have seen / understand:
everything about agile, scrum, and sprints seem

inefficient
horrible to work with
disconnected from reality
bloated
(at least for our type of work)

But... I like the word sprint so here is my version

Styles of development

Kanban, issues, sprints

Sprint

A short time-period (2-4 weeks)
A clear goal achievable during this time
Pre-made plan to reach that goal
Applied to already mature software

Styles of development

Kanban, issues, sprints

Sprint

An example

We need to refactor the library interface to support all the new features and go from v1.8.1 -> v2.0.0
Plan:
Person 1) update interface and documentation
Person 2) update tests
Person 3) update examples
Person 4) add long overdue new internals
Person 5) updates dependant code we maintain

Styles of development

Building up novel components

Iterative and incremental development
Software prototyping

Building up well-known components

Test-driven development

Maintaining code

Kanban, issues, sprints

The fallback style

The "None" pattern - just do it

Styles of development

The "None" pattern - just do it

Perfect for

the one-off code
the lone script
the throwaway prototype
the quick-fix
...

Styles of development

Reality check

Defining strict methods fine but in the end

Use a combination of everything that works
The ultimate deciding factor is results:

functionality & correctness
longevity
performance
development time
usability
...

how you get there is up to you

Styles of development

Reality check

Tools for project management

Plain text / markdown files
Obsidian (markdown vault)
Gitlab issues / todo / kanban
Gantt charts (obsidian/GanttLab/...)
Todo-list management (pter, ...)

Styles of development

Tools for project management

Styles of development

Tools for project management

Research plan

Styles of development

Further study and homework

Let's check out the handout above!