Fail fast and cheap II
Follow up of Fail fast and cheap with practical applications.
Interactive programming
If you haven’t watched Inventing on Principle by Bret Victor, I would highly recommend it. In the talk he demonstrates what a fully interactive programming environment could look like. To my knowledge we don’t really have any tools quite like that.
What can you use to at least approximate what Bret Victor shows in his talk?
REPL Driven Development
Really fast unit testing
Small REPL driven scripts to test isolated logic
Advanced debuggers
Print statements
REPL Driven Development
What lisp offers. I’m unsure which other niche languages offers this option, but the offerings from mainstream languages on the REPL can be thin.
It lowers the cost of experimentation, development of new features and debugging.
Really fast unit testing
If you can get the unit testing cycle time to below a second for whatever you’re writing, you can use it as a proxy for interactive development where you at least get really fast feedback.
It lowers the cost of fixing errors.
Poor man’s REPL
REPLs like Python’s can still be very valuable. By isolating what you wish to develop, it’s possible to setup small scripts that will load everything you need, allow for reloading and evaluating code on tricky parts in the codebase that you’re working on.
It lowers the cost of experimentation.
Advanced debuggers
Advanced debuggers will allow you to edit the code in the running program, recompile it, and then continue with the edits.
It lowers the cost of failure by making it cheap to fix errors.
Print statements
The good old print statement. In here I would include tracers and anything that allows you to follow the flow such as observability tools.
If you can’t use a debugger to find problems, using print statements can be really good to follow the flow of the program as it actually happens, as opposed to how you think it happens.
It lowers the cost of misunderstanding.
Debuggers
For the love of God! Learn to use a debugger. Also read my ragtag collection of techniques for debugging.
It lowers the cost of discovery, error fixing and misunderstanding of how your code actually works.
Talking with stakeholders
Talking with stakeholders is part of a bigger responsibilty: Understanding the problem you are tasked with solving. Early in my career I sometimes made the mistake thinking I had understood the assignment. When I later on presented my solution, I was told X, Y and Z were wrong. Had I simply talked with the stakeholders, I would quickly have found out mistakes in my assumptions.
It lowers the cost of misunderstandings and builds shared understanding.
Whiteboards/pen and paper for understanding a wall of text
Sketching out your understanding of a wall of text you just read on a whiteboard/piece of paper will often, very quickly, show misunderstandings.
Part of the beauty of whiteboards is that you force yourself to explain the problem, and explaining a problem requires a deep understanding of the problem.
It lowers the cost of discovery of misunderstanding.
Pen and paper/Whiteboard
The mere act of writing things down and sketching out solutions forces you to choose. Choosing forces evaluation.
It lowers the cost of going down the wrong path.
Keep discarded solutions
For a sufficently advanced problem, keeping discarded solutions in an archive can be very beneficial for future you, or the axe-wielding maniac who takes over maintenance of your code. Those discarded solutions represent hours or days of exploring alternatives to a tricky problem. Being able to go back in time and see the reasoning can be invaluable in avoiding pitfalls that were already explored.
Note |
It doesn’t have to be a an entire mock solution. Just a few
sentences that explains why something was not chosen is often more
than good enough. If it’s particulary tricky, explain in more detail,
but it shouldn’t be a massive undertaking writing down The why of
why something was discarded.
|
It lowers the cost of re-disovering why a particular solution was picked.
Comments
When writing down comments in code, it’s a lot more beneficial to
write down why something is the way it is, rather than explaing what
is done. The why explains the reason behind the code existing in the
first place, the how I can understand from reading the code, but
rarely can I reason out the why from the how. The best example I
ever saw of this, was a big massive explanation of how a piece of
hardware worked at the top of a big chunk of code that was very
complex. Once you read through that comment the code made a lot more
sense. Without the comment you would be at a loss as to what it does,
and why it does that.
It lowers the cost of misunderstandings.
Nullable code
My new favourite toy. Nullables has allowed me to work with logic that is deeply tied to enviroments where the code will run, but it stricly speaking doesn’t need access to, in order to test the logic. Mind you, it still needs testing against the environment.
It lowers the cost of experimentation and testing.
This was a braindump. I hope it helps.
