Cross-Pollination of Ideas
Software engineering has always been a magpie discipline. Many of its best ideas were not invented here — they were noticed somewhere else, translated, and put to work. This page is about cultivating that habit deliberately: spotting a structure that works in one domain and asking, "what is the equivalent over here?"
Engineering's Borrowed Wardrobe
- Design patterns came from building architecture — Christopher Alexander's A Pattern Language described recurring solutions to recurring problems in towns and buildings twenty years before the Gang of Four applied the idea to code [1].
- Scrum was named and shaped by a Harvard Business Review study of manufacturing teams at Honda, Canon and Fuji-Xerox [2].
- Kanban is Toyota's factory-floor signalling system, re-imagined for work-in-progress limits on software teams.
- Genetic algorithms and simulated annealing borrow their search strategies from evolution and metallurgy respectively.
- Behaviour-Driven Development grew from TDD plus the "ubiquitous language" of domain-driven design — a linguistics-flavoured idea about shared vocabulary. We even use BDD's Given/When/Then structure for marking student projects on this site.
The pattern in all of these: someone understood the structure of a solution well enough to separate it from its original clothing.
Why It Works (and When It Doesn't)
Analogy is a compression trick. A mature field has already paid — in years and failures — to learn which shapes of solution survive; borrowing the shape lets you skip part of the bill. But an analogy transfers assumptions along with structure, and those need auditing. Toyota's kanban assumes work items are roughly interchangeable; software tasks often are not. The test of a good borrowing is not "does the metaphor feel apt?" but "do the load-bearing assumptions still hold?"
Case Study: GOAP as a Project Planner
Goal-Oriented Action Planning gives game characters a goal and a set of actions — each with preconditions, effects and costs — and lets a search algorithm derive the sequence. Read that sentence again with a project manager's hat on:
| GOAP concept | Project planning equivalent |
|---|---|
| World state (symbols) | Project state: design_approved, api_stable, security_review_done |
| Action preconditions | Task dependencies ("can't deploy before the review") |
| Action effects | Deliverables a task produces |
| Action cost | Effort estimate (or risk-weighted effort) |
| Goal state | Release criteria / definition of done |
| Replanning on surprise | Responding to a failed task without redrawing the whole plan |
Feed those into the same planner and interesting things fall out:
- Plans are derived, not drawn. Instead of maintaining a Gantt chart by hand, you maintain the facts — what each task needs and produces — and regenerate the plan whenever they change. This is the classic critical-path method, but with the emphasis moved to keeping the action model honest.
- Replanning is routine, not a crisis. When a task fails or a dependency slips, the planner simply searches again from the new state — exactly how an agile team wants to treat a broken sprint.
- Costs expose priorities. If the derived plan routes around your favourite feature, the model is telling you its cost/benefit doesn't justify its place on the critical path. Argue with the model, not the chart.
- "No plan exists" is a first-class answer. A planner that cannot reach the release criteria from the current state is an early warning most methodologies deliver far too late — compare the early-warning theme in Risk Management.
The caveats are the assumption audit from the previous section: people are not deterministic operators, estimates are distributions rather than scalars, and effects in human systems have side-channels no symbol captures. Treat a GOAP-style project planner as a reasoning aid that keeps your dependency model honest, not as an autopilot.
Cross-Pollinating Deliberately
- Read one field over from your own. Games people should read operations research; web people should read control theory; everyone should read a little biology.
- Translate vocabulary first. Write the mapping table (like the one above) before writing any code — if the table has empty rows, the analogy is decorative.
- Audit the assumptions. List what the original field takes for granted and check each item against your domain.
- Prototype small. A borrowed idea earns its place with a demonstration, not a slide deck.
References
- Alexander, C., Ishikawa, S. & Silverstein, M. (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press. https://global.oup.com/academic/product/a-pattern-language-9780195019193
- Takeuchi, H. & Nonaka, I. (1986). "The New New Product Development Game." Harvard Business Review, 64(1), 137–146. https://hbr.org/1986/01/the-new-new-product-development-game
- Orkin, J. (2006). "Three States and a Plan: The A.I. of F.E.A.R." Game Developers Conference 2006. https://www.gamedevs.org/uploads/three-states-plan-ai-of-fear.pdf