This section is for people who need software projects to become more predictable without burying the team in process.
The core idea is simple: software goes wrong when users, developers, reviewers, and operators stop sharing the same picture of what is being built. These practices keep that picture visible from first conversation through release.
Start With the Workflow
Read these in order if you want the main software delivery path:
- Software is Hard explains why projects drift and why feedback loops matter.
- Use Cases captures user goals in plain language.
- Use Cases to Tasks turns user value into testable implementation work.
- Organizing Software Projects with Kanban keeps work visible and limited.
- Test Driven Software Development makes expected behavior repeatable.
- Peer Reviews catches design and behavior problems before they ship.
- Release Process turns finished work into versioned, recoverable user value.
Supporting Practices
These articles support the workflow without being the main sequence:
- Version Control Systems treats history, branches, reviews, and tags as project infrastructure.
- Wireframes and Storyboards helps teams reason about user flows before implementation.
- Fixed-Point Numeric Types in Go Financial Software shows domain modeling and correctness in a narrow technical area.
- The Strategy Pattern in a Backtesting Engine shows how interface design keeps simulation and production logic aligned.
How to Use This Section
The software articles are the canonical guidance for delivery practices. Project pages show those ideas inside larger systems. Notes are smaller observations or historical references that may not be as polished as these articles.