If architects had to work like programmers (1995)
A 1995 humor piece imagining architects forced to work under software-industry conditions sparks broader critique of how modern tech projects are run: vague and shifting requirements, unrealistic timelines, heavy process, and “responsibility without authority.” Commenters compare software to construction and other engineering fields, debating whether programming should be more like regulated, liability-heavy physical design or whether its malleability justifies iterative chaos. Many blame corporate incentives, MBA culture, and cargo‑cult “Agile” for dysfunction, while others note that clients, bad specs, and political constraints are universal across professions.
Overall reaction to the satire
- Many find the piece painfully accurate for modern software work, especially around vague requirements, shifting demands, and arbitrary constraints.
- Others see it as overblown “programmer victimhood” that ignores similar dysfunction in other project-based fields.
- Several note the article is clearly humor, but that it resonates because it reflects common industry pathologies.
Parallels with real-world construction and architecture
- People with construction/architecture experience report remarkably similar issues: indecisive or status-seeking clients, last‑minute changes, unrealistic ideas (e.g., rooftop or podium pools added late), and specs that are incomplete or wrong.
- High-end residential and “rich client” work reportedly looks very much like the satire: constant redesigns, fads from magazines, and whimsical structural demands.
- Others emphasize differences: architects and engineers face strong regulation, personal legal liability, safety concerns, and slower, more expensive change cycles.
Key pain points in software development
- Estimation under uncertainty: tiny specs, forced atomization of work into “points,” and being punished regardless of estimate accuracy.
- “Responsibility without authority”: being blamed for issues you’re not allowed or enabled to fix.
- Constant interruption: emergencies, context switches, and mandatory status meetings that don’t adjust deadlines.
- “Corporate agile” is widely criticized as ceremony-heavy, micromanaging, and detached from the original agile ideas.
Role of managers, PMs, and clients
- Some argue good product/project managers should shield engineers from chaotic clients; others say PMs often become another source of chaos and micromanagement.
- There is disagreement on whether developers should talk directly to customers: some see it as essential to understand problems; others warn about promise-making and expectation management.
Debate over analogies: software vs physical engineering
- One side: construction and software are fundamentally different (bytes vs bricks, reversibility, feedback speed, role fragmentation), so the analogy is “false.”
- Other side: analogies are still useful to expose how outrageous certain software expectations are when mapped to a physical domain.
Broader organizational/management critique
- Several comments blame “MBA-ification,” spreadsheet-driven decision-making, quarterly-focus, and professional managers detached from the work.
- Others note that virtually all large organizations are dysfunctional, across both software and traditional engineering.