Software Haiku
Posted on 2020-06-01

Let's break the ice with some software development-related haiku. I wrote these a while back to encapsulate some tips, observations, and hard-earned wisdom gained over the course of my career.

Write your unit tests
As you implement features
Protects your progress.

Writer's block? Start with
Unfilled declarations of
Core data objects.

Keep a toolkit of
Tech notes, code samples handy
Maintains momentum.

Understanding C
Pointers - some get it, others
Can really struggle.

Random crashes are
Likely corrupt memory
Or FS glitches.

Heisenbugs: when you
Add code or tools to debug
The bug goes away.

Be firm on getting
Clear requirements, or else
Work will be wasted.

Different groups will have
Different assumptions. Projects
Need clear, detailed specs.

Assume assumptions
And dig deep when gathering
The requirements.

They may use the same
Words, but their mental models
Are very different.

Code simplicity
Is best, with exceptions for
Runtime performance.

Duplicated code
Makes it less maintainable
Consolidate it.

Assumptions should be
Codified with assertions
Saves a lot of work.

Infrastructure needs
To be long term and solid
I won't add your hack.

Better quality
Leverage automation for
Testing and audits.

In testing is useful to
Find corner-case bugs.

If something was hard
To debug, add helper code
To assist next time.

To reduce header
Dependencies: Pointer-to-

When a problem is
Hard to grasp entirely
Divide into parts.

A struct size culprit
Memory alignment holes
Be mindful of that.

Variables make bugs less

Commenting your code
You'll skip it when in-the-zone
With later regret.

Design for future
Scale and features to ensure
Less technical debt.

Future-proofed code is
Data-driven and doesn't
Have size assumptions.

Conserve memory
Avoid duplicated and
Redundant data.

Good data design
Protects you from internal

Data ownership
Should be clear and consistent
In system design.

"Lazy" computing
Don't compute results until
Callers request it.

Add enum values
At the bottom, not middle
Avoids disruption.

Safely multithread
By data partitioning
Or mutex a lot.

Make multithreading
Faster: reduce contention
Use less mutexing.

Don't assume input
Is clean. Check it and give good
Error messages.

Services open
To the internet require
Paranoid thinking.

Internet randos
Sanitize their input or
Suffer dropped tables.

Get work that others
Depend on done first - stay off
The critical path.

Return codes: Always
Check and gracefully handle
Saves debugging time.

Very annoying
When they misuse your feature
And then make complaints.

It's already been
Tested and debugged, so use
Common modules.

I know it's fun to
Develop data structures
But try to reuse.

Make names descriptive
This is known as implicit

Consistent naming
Conventions saves time, helps with

Make design choices
That increase robustness and

Tabs: An artifact
From when storage was scarce. Please,
Don't use. They are gross.

A hidden culprit
Of I/O problems can be
NFS file locks.

Embedded software
Woes: sometimes hardware failure
Is the bug culprit.

C preprocessor
Macros: Use with caution, has
Few safeguards with use.

Never rely on
The order of destruction
Of static objects.

Use deques instead of
Vectors to add or remove
Objects at its front.

C and C++
Share syntax, but have different
Design, code patterns.

Syntax error: you
Mis-typed. Static cast error:
You also mis-typed.

Sometimes a 'hang' is
Not a hang, but just bogged down
With complexity.

Automate backups
But regularly check that
They are working right.

Might be the snapshots
When your network disk stays full
When deleting files.

CPU load's a
Poor multithreading measure
Wall-clock time's better.

Beware of same-named
Variables at lower
Scope in the function.

C gotcha: using
One 'equal' sign, not two, for
"Is-equal" checking.

C gotcha: leaving
End-of-line semicolons
After "for" and "if".

The first compiler
Error may expose the source
Of the rest of them.

Segmentation fault
You wrote to memory you
Didn't allocate.

Be methodical
When debugging - keeps you from
Going in circles.

Use hardware breakpoints
In gdb to catch when
Variables change.

When clients can set
Linkages, always check for
Cycles, and handle.

To reliably
Release locks, do so in a
Stack object dtor.

If you're not really
Busy, then you're in danger
Of being laid off.