It Can Be Done (2003)
Anecdotes about André Bensoussan designing a complex Multics file-system component entirely on paper spark a broader debate about how software was — and could still be — built with deep focus, clear requirements, and minimal tooling. Commenters contrast that era’s quiet offices, small but conceptually hard systems, and strong domain mastery with today’s interrupt-driven workflows, shifting specs under “agile,” and sprawling stacks of poorly documented dependencies. Many see careful up‑front design, close collaboration with domain experts, and written design docs as undervalued skills that could significantly improve modern software quality, even if the constraints that once forced such rigor no longer exist.
Pen-and-Paper Programming & Historical Context
- Many recall learning or working with very limited computer access (paper, punch cards, week-long compile cycles).
- This forced careful reasoning, fewer iterations, and often led to code that worked on first run.
- Several see the Multics story as part of a broader “measure twice, cut once” era when compute time was scarce and terminals were distraction-free.
- Others note this might also have acted as a filter: only highly motivated people persisted under those constraints.
Requirements, Edge Cases & Changing Specs
- Strong agreement that clear, stable requirements and well-defined APIs make high-quality code far more achievable.
- Modern problems: ambiguous goals, late stakeholder feedback, constant scope changes labeled “agile,” and pressure for deadlines and “velocity.”
- Debate over agile: some say it responds to inevitable requirement changes; others say it normalizes constant churn and encourages irresponsible change.
- Edge cases are a major source of bugs and complexity. Some argue rare cases should be handled manually; others say at scale even 1% affects millions and must be engineered.
Design, Documentation & Thinking Before Coding
- Several stress that being able to write down the problem and proposed solution is a sign of true understanding.
- Short design docs and diagrams are framed as thinking tools, not bureaucracy.
- Some struggle to design on paper, claiming they only understand systems while typing and iterating; others say this is a trainable skill.
- Test-driven development is suggested as a modern analogue to “design first.”
Domain Expertise & Engineering Mindset
- A key reason the Multics feat was possible: the programmer was also a deep domain expert.
- Many argue real value lies in understanding the problem domain and shaping requirements, not just translating specs into code.
- There’s concern that many modern developers lack full-stack understanding and treat performance and robustness as afterthoughts.
Work Environment, Scale & Emotional Reactions
- Older environments: quiet private offices, large desks, no notifications, technically savvy management.
- Today: interruptions, meetings, tool sprawl, and ever-growing interconnected systems and external APIs.
- Some are inspired and nostalgic; others are skeptical, noting that modern complexity and messy integrations make “one-pass” perfection unrealistic.
- A recurring sentiment: many developers feel underused, doing low-impact CRUD/ad work instead of foundational systems, leading to frustration and cynicism.