Towards an Ideal Development Workflow

Oct 04, 2024

Ideal Dev environment:

Phase 1 Development

Develop product ideas iteratively

try out an idea
test idea(s) using fail-fast approaches
- build prototype code as quickly as possible, then use it and try it out
- poke at the idea and try to find out why it doesn’t work as well as expected and figure out how to improve on the idea
revise the idea
try again
repeat until satisfied

REPL
late binding
dynamic languages, like Lisp, Smalltalk, Self, Prolog, etc.
nano-DSLs to succinctly describe each aspect of the design
- use nano-DSLs to describe intended actions and operations instead of dealing with niggly details of implementation
- Lispers use macros as a form of nano-DSLs
shell pipelines
- It’s OK to use heavy-weight processes - on development machines - to rough-in product functionality (Production Engineering will get rid of the inefficiencies)

Minimum Viable Implementation
Build a working version of the best idea from Phase 1
Steal code from Phase 1
Skimp on efficiency, don’t skimp on product features
Phase 2 might turn out to be a no-op, since code from Phase 1 might be “good enough” for an MVI

Production engineer the best variant of the solution, i.e. improve the efficiency of the MVI

tools & languages that help create an assembler version of the solution
use strong typing
use static scoping, syntactic binding
white box testing, path (coverage) testing
most modern languages are geared for this kind of activity, e.g. Python, Haskell, etc.
- conflating Development and Production Engineering results in accidental complexity
- current crop of languages emphasize Production Engineering, thus, they make Development more difficult

send improvement ideas back to Phase 1 to begin a new cycle of development for a new product or for V2.0 of product