Two Directions, One Solution

Computational thinking builds understanding bottom-up and adaptive design reuse assembles solutions top-down — a real build runs both directions at once and meets in the middle.

Watch a small team build a neighborhood-library lending system. Bottom-up first: the problem decomposes (0043) into cataloging, borrowing, returning, and overdue notices; pattern recognition (0044) notices that borrowing and returning are one movement run in two directions; abstraction (0045) keeps member, item, and due date, and drops everything else about a book but its identity. The team drafts the overdue-notice algorithm in pseudocode (0050), and where the rule for a borrowed item containing borrowed items appears — a box set holding discs — recursion (0055) handles the nesting with a base case at the single disc. Then the top-down direction takes over: nobody writes a login system or a reminder-mailer from scratch, because adaptive design reuse (0061) supplies both as design components (0062) needing minimal change. The system's shape follows a known architectural pattern (0063): data separated from display separated from interaction — Model-View-Controller (0070) — stacked in layers (0065) so the checkout desk's screen never touches the database directly, and cut into components (0066) so the mailer can be swapped without touching the catalog. The whole is judged as a business solution architecture (0067): sound if members, librarians, and the overdue process get what they need, unsound otherwise, whatever the diagram's beauty. Testing (0049) then earns the verdict. Both directions were present the entire time — decomposition finding the parts, reuse supplying the parts already built — and the finished system cannot say which direction built it, which is the mark of the method working.