The Architecture of Order: An Analysis of 'Always Be Knolling' in Software Engineering

1. Introduction: The Entropy of the Digital Workspace

Software engineering is, fundamentally, a battle against entropy. In the physical universe, thermodynamics dictates that systems tend toward disorder; in the digital universe, this disorder manifests as technical debt, "bit rot," and the sprawling complexity of legacy codebases. As systems grow, the cognitive load required to maintain them increases, often non-linearly, until the act of creation is paralyzed by the necessity of maintenance. To combat this, the industry has developed a plethora of methodologies—Agile, Scrum, DevOps, Domain-Driven Design—aimed at managing the flow of work. Yet, amidst these high-level process frameworks, there exists a visceral, tactile philosophy of organization that creates a bridge between the physical discipline of the workshop and the abstract discipline of software: "Always Be Knolling."

Originating not in a computer science lab but in a furniture fabrication shop, "knolling" is the practice of organizing tools and materials in parallel lines or at 90-degree angles to maximize visibility and minimize search time. While initially a technique for physical hygiene, its translation into software engineering offers a profound framework for understanding code quality, refactoring, and developer productivity. It reframes "clean code" not merely as a set of rules to be obeyed for compliance, but as an aesthetic and functional necessity for cognitive clarity.

2. The Genesis and Evolution of the Philosophy

To fully appreciate the application of ABK in software, one must first understand its industrial origins. The term is not a metaphor invented for the digital age; it is a specific historical practice rooted in the interplay between utility and modernism.

2.1 The Frank Gehry Connection and Andrew Kromelow

The etymology of "knolling" traces back to 1987 in Santa Monica, California, within the furniture fabrication shop of the renowned architect Frank Gehry. At the time, Gehry was designing a collection of chairs for Knoll, a brand synonymous with mid-century modernism and the angular, grid-based designs of Florence Knoll.  

Andrew Kromelow, a janitor at the shop, observed a recurring problem: the fabricators would leave their tools in chaotic piles at the end of the day, leading to lost time and frustration the following morning. Kromelow began a nightly ritual. He would scour the workshop for misplaced tools, group them by size, function, or type, and arrange them on the workbenches in strict parallel lines or at 90-degree angles.  

This act was functional—it allowed the workers to see exactly what inventory was available at a glance—but it was also aesthetic. Kromelow called the practice "knolling" because the right angles mimicked the design language of the Knoll furniture they were building. It was an imposition of order upon chaos, transforming a messy workbench into a visual inventory.  

2.2 Tom Sachs and the 10 Bullets Manifesto

While Kromelow invented the practice, it was the artist and sculptor Tom Sachs who codified it into a religion. Sachs, who spent two years working in Gehry's shop as a fabricator, adopted knolling as a core tenet of his own studio practice. For Sachs, the chaotic nature of creative work required a rigid underlying structure to prevent the artist from being overwhelmed.  

In his 2009 studio manual and video manifesto, 10 Bullets, Sachs formally established the rule: "Always Be Knolling" (ABK). The phrase is a deliberate subversion of the famous sales mantra "Always Be Closing" (ABC) from the film Glengarry Glen Ross. Where "Always Be Closing" represents the aggressive, transactional nature of capitalism, "Always Be Knolling" represents the meditative, generative nature of craftsmanship. It shifts the focus from the result (the sale) to the process (the readiness).  

Sachs defined the protocol for ABK with four explicit steps, which form the structural backbone of this analysis:

1. Scan your environment for materials, tools, books, music, etc., which are not in use.
2. Put away everything not in use. If you aren't sure, leave it out.
3. Group all 'like' objects.
4. Align or square all objects to either the surface they rest on or the studio itself.  

2.3 Cultural Diffusion: The Maker Movement and Software

The philosophy bridged the gap to the broader engineering community largely through Adam Savage of MythBusters fame. Through his Tested platform, Savage championed knolling not just as a cleaning habit but as a cognitive tool for complex builds. Savage introduced the concept of "First Order Retrievability"—the idea that a tool should be accessible without having to move another object. This concept resonates deeply with software engineers, who strive for low-latency access to information and logic.  

3. Theoretical Underpinnings: Entropy and Cognitive Load

Before dissecting the four steps, it is necessary to establish why knolling works in a non-physical environment. Software is invisible; why does its "shape" matter?

3.1 The Broken Windows Theory and Software Entropy

The "Broken Windows Theory" suggests that visible signs of disorder (like a broken window) encourage further disorder and crime. In software, this is empirically observable. A codebase with inconsistent formatting, dead code, and poor naming conventions signals to developers that "care" is not required. This leads to what pragmatic programmers call "software rot" or entropy.  

Knolling is the counter-force to entropy. It is the active expenditure of energy to maintain order. By enforcing a visual and structural standard ("Always Be Knolling"), a team signals that the environment is controlled and cared for. This aligns with the "Boy Scout Rule" advocated by Robert C. Martin ("Uncle Bob"): "Leave the campground cleaner than you found it". The act of knolling—aligning the code before leaving the file—is the practical application of this rule.  

3.2 Cognitive Load and the "Scan" Pattern

Software engineering is primarily a reading activity. Studies indicate that developers spend significantly more time reading code than writing it. This reading process is heavily influenced by the visual presentation of the information.  

Eye-tracking studies on code review reveal a "scan" pattern: effective reviewers spend time initially scanning the overall structure of the code before diving into details. Reviewers who fail to "scan" effectively take longer to find defects. A "knolled" codebase—where indentation is consistent, and related functions are grouped—facilitates this scanning process. It reduces "extraneous cognitive load"—the mental effort required to process the presentation of the information—allowing the developer to focus on "intrinsic cognitive load"—the difficulty of the logic itself.  

3.3 The Aesthetic-Usability Effect

Research into "code beauty" suggests that the aesthetic quality of code is not merely subjective. Snippets from the International Conference on Technical Debt indicate that code beauty metrics correlate with technical debt interest. Developers perceive aesthetically pleasing code (consistent, aligned, grouped) as higher quality and more maintainable. This is the "Aesthetic-Usability Effect" in action: we are more forgiving and effective when interacting with systems that are visually ordered. Knolling, therefore, is not decoration; it is usability engineering for the developer.  

4. Step One: SCAN (Observability and Perception)

The first step of the Sachs protocol is: "Scan your environment for materials... which are not in use."

In a physical workshop, this involves stepping back to view the workbench. In software, where the "workbench" can contain millions of lines of code across thousands of files, "scanning" requires deliberate techniques and tooling to achieve observability.

4.1 "Interrogating" the Codebase

When a developer enters a new or legacy codebase, they must perform an initial scan to build a mental model of the system. This is often referred to as "interrogating the code".  

• Entry Point Identification: The scan begins by locating the main() function, the index.js, or the App.tsx. This anchors the developer's mental map.  
• High-Level Structure: Just as Kromelow would assess the layout of the shop, a developer scans the directory structure. Is it grouped by technical layer (Controllers, Views) or by domain feature (Checkout, User)? This initial scan reveals the architectural intent (or lack thereof).  
• Dependency Auditing: A critical part of the scan is reviewing package.json, pom.xml, or requirements.txt. This provides an inventory of the "tools" currently available in the project. An "Always Be Knolling" mindset looks for dependencies that are outdated or unused—tools that are cluttering the bench.  

4.2 Automated Scanning: Static Analysis

In the digital realm, we can automate the "scan." Static Application Security Testing (SAST) tools, linters (ESLint, Pylint), and complexity analyzers (SonarQube) act as the janitor's eyes, tirelessly scanning the environment for anomalies.  

• Cyclomatic Complexity: Tools that measure complexity allow developers to "scan" for hot spots—functions that are too dense or tangled. These metrics provide a heatmap of disorder, guiding the developer to areas that require "knolling" (refactoring).  
• Visualizing the Mess: Advanced tools like CodeMap or architecture visualizers generate dependency graphs. These tools literally "layout" the code on a 2D plane, allowing the developer to see the "spaghetti" connections that remain invisible in a text editor. This visualization is the closest digital equivalent to the physical act of laying tools out on a floor to see what you have.  

4.3 The Psychology of the Scan

The "scan" is also a mental reset. Adam Savage notes that knolling provides a "mental break" and allows the subconscious to work on problems. Similarly, the act of reading through code without editing—simply tracing execution paths and understanding data flow —is a necessary preamble to effective modification. It prevents the "flailing" that occurs when a developer dives into a bug fix without understanding the surrounding context.  

Table 1: The "Scan" Phase Comparison

5. Step Two: PUT AWAY (Elimination and Reduction)

The second step is: "Put away everything not in use. If you aren't sure, leave it out."

This is the discipline of elimination. In a physical shop, leaving unused tools on the bench creates hazards. In software, unused code creates "cognitive hazards"—distractions that confuse readers and potential vectors for bugs or security vulnerabilities.

5.1 The Scourge of Dead Code

"Putting away" in software primarily means deleting dead code. Code that is commented out, unreachable, or superseded by newer logic is "matter out of place."

• Commented-Out Code: Developers often leave blocks of commented-out code as a safety net. The ABK philosophy, supported by "Clean Code" principles, dictates that this is unnecessary hoarding. Version Control Systems (Git) are the ultimate "storage cabinet." If code is deleted, it is effectively "put away" into the Git history, retrievable if needed, but removed from the active "workbench" (the master branch).  
• Unreachable Branches: Static analysis tools (the "scan") identify logical branches that can never be executed. "Putting away" means pruning these branches to simplify the control flow.  
• YAGNI (You Ain't Gonna Need It): The Extreme Programming principle of YAGNI aligns perfectly with Sachs’s rule: "If you aren't sure, leave it out." Implementing features for hypothetical future use is the equivalent of cluttering the workbench with tools you might need next week. It impedes the work of today.

5.2 Managing Dependencies and "Bloat"

"Putting away" extends to the supply chain. Modern applications often suffer from "dependency bloat"—importing massive libraries for minor utility functions. An audit of the node_modules or library path often reveals "tools" that are not in use.

• Tree Shaking: Modern build tools (like Webpack or Rollup) perform "tree shaking"—automatically "putting away" (excluding) the parts of libraries that are not actually imported by the code. This is automated knolling of the final build artifact.
• Security Implications: Unused dependencies are not just clutter; they are liabilities. As noted in security audits, "unattended libraries" are vectors for supply chain attacks. "Putting them away" (uninstalling them) reduces the attack surface.  

5.3 The "Clean As You Go" Ritual

In professional kitchens, the practice of mise en place includes "clean as you go." In software, this is micro-refactoring. As a developer works, they should be continuously "putting away" temporary variables, consolidating duplicate logic, and removing debug print statements (console.log). The instruction "If you open a file... you must make at least one improvement before you can close it" ¹ ensures that the entropy of the system is constantly being reduced.  

Another Valuable Practice from the Kitchen: Clean as You Go - Embedded Artistryembeddedartistry.com/blog/2021/05/24/another-valuable-practice-from-the-kitchen-clean-as-you-go

6. Step Three: GROUP (Cohesion and Architecture)

The third step is: "Group all 'like' objects."

In the workshop, this implies putting all screwdrivers in one zone and all pliers in another. In software architecture, this translates to the fundamental principles of Cohesion and Coupling.

6.1 The Principle of Cohesion

"Grouping like objects" is the lay definition of High Cohesion. Cohesion refers to the degree to which the elements inside a module belong together.  

• Single Responsibility Principle (SRP): A class or function should have one reason to change. If a module handles both "calculating sales tax" and "generating PDF invoices," it violates the "Group" rule. These are unlike objects. One is a mathematical logic; the other is presentation logic. They should be ungrouped and moved to their respective "drawers".  
• Colocation: The definition of "like objects" has evolved. Historically, web developers grouped by file type (HTML, CSS, JS). Modern component architectures (React, Vue, Svelte) argue that the HTML, CSS, and JS for a single button are "like objects" and should be grouped together in the same file or folder. This "Component-Based Knolling" acknowledges that functional relatedness is more important than technological relatedness.  

6.2 Separation of Concerns (SoC)

Grouping like objects implies separating unlike objects. This is the Separation of Concerns.

• Layered Architecture: In a "knolled" system, business logic does not leak into the database layer, and UI logic does not leak into the network layer. Each layer is a distinct "group" of functionality.  
• The Modular Monolith: For large systems, the "Modular Monolith" architecture applies knolling at the macro scale. Instead of a giant "spaghetti" codebases, the system is divided into strict modules (e.g., Inventory, Billing, Shipping) with defined boundaries. This grouping allows teams to work on specific "tables" without disturbing the tools on another.  

6.3 Folder Structure and the "Drawer" Metaphor

The directory structure is the physical manifestation of the "Group" rule.

• Domain-Driven Grouping: Organizing folders by feature (e.g., /features/cart, /features/user) rather than by type (e.g., /controllers, /views) is increasingly favored. It keeps all the tools required for a specific task in one place.  
• The Utility Drawer: Every project has a utils or common folder—the "junk drawer" of software. While necessary, ABK dictates that this drawer must be organized. Utilities should be grouped by domain (e.g., date-utils, string-utils) rather than dumped into a single helpers.js file.  

6.4 The Trap of Premature Modularization

There is a risk of over-adherence to this rule, known as "Premature Modularization" or "Over-Engineering". This occurs when a developer creates complex abstraction layers and folder structures for a simple application. This is akin to building an elaborate pegboard system for three screwdrivers.  

• Yak Shaving: Sometimes, the desire to perfectly "group" and organize code leads to "Yak Shaving"—a regression into endless preparatory tasks that prevents the actual work from being done. The ABK philosophy must be balanced with pragmatism: group objects only when the cognitive load of not grouping them exceeds the effort of organization.  

Table 2: Grouping Strategies

7. Step Four: ALIGN (Formatting and Aesthetics)

The final and most visually recognizable step is: "Align or square all objects to either the surface they rest on, or the studio itself."

In software, this is Code Formatting, Linting, and Standardization. It is the enforcement of a visual grid upon the text.

7.1 The Visual Grid: Indentation and Whitespace

Code is text, but it is read structurally. Indentation is the primary mechanism for indicating hierarchy (scope).

• The Rhythm of Code: "Knolled" code has a visual rhythm. If one function is indented with 2 spaces and another with 4, the visual grid is broken. This irregularity acts as a "stumble" for the eye, increasing scan time.  
• Vertical Alignment: Some developers practice "vertical alignment," where variable assignments are aligned by the equals sign:JavaScript

const name    = "John";
const age     = 30;
const address = "123 Main St";

While controversial (as it requires maintenance), this is a pure expression of the ABK "align" rule, creating a satisfying visual order that aids in scanning the data.  

7.2 The Joy of Auto-Formatters

The most significant advancement in "software knolling" is the widespread adoption of opinionated auto-formatters like Prettier (JavaScript), Black (Python), and gofmt (Go).

• Automated Alignment: These tools remove the human element from alignment. They parse the code and re-print it according to a strict set of rules, ensuring that every file in the project is "squared to the studio".  
• Ending "Bikeshedding": In the past, teams wasted hours arguing over brace placement or line length—a phenomenon known as "bikeshedding". Auto-formatters eliminate this. The "studio rules" are encoded in the software, and the developer submits to the algorithm. As one article notes, "All your code should be formatted before it's committed. And you shouldn't have to think about it".  

7.3 Naming Conventions as Semantic Alignment

Alignment is not just spatial; it is semantic. "Aligning" the names of variables and functions means adhering to a consistent convention (CamelCase, snake_case, PascalCase).

• Cognitive Prediction: When names are aligned to a standard (e.g., boolean variables always start with is or has), the developer can predict the name of a variable without looking it up. This is "First Order Retrievability" applied to nomenclature.  
• Symmetry: Code exhibits symmetry. open() implies close(). create() implies destroy(). If a codebase uses create() in one module and make() in another, the alignment is broken. ABK demands consistency across the entire system.  

7.4 The "House Style" and Uniformity

Tom Sachs emphasizes "working to code"—following the specific rules of his studio to ensure that the work looks like it came from the studio, not an individual. In software, this is the Style Guide (e.g., Google Java Style, Airbnb JavaScript Style).

• Ego Erasure: Adopting a strict house style requires the developer to suppress their personal idiosyncrasies (ego) in favor of the collective order. The result is a codebase that is uniform, predictable, and easier to maintain by the group.  

8. The Digital Workbench: Optimizing for Flow

Just as a physical workshop should invite creativity, your digital environment needs to be a "place of Zen" where code flows without obstruction. This starts with the IDE as a cockpit; utilizing "Zen Mode" or minimalist themes isn't just aesthetic—it strips away cognitive load, allowing you to focus entirely on the logic at hand.

Crucially, we aim for "First Order Retrievability"—Adam Savage’s rule that you should be able to grab a tool without moving anything else. In software, this means mastering Command Palettes and Fuzzy Finders (Cmd+P). When you can summon any file or function with a few keystrokes rather than digging through folder trees, you move from "managing files" to pure creation.

9. Insights, Implications, and the Future

9.1 The Psychology of Readiness

The most profound insight of ABK is that it is not about cleaning; it is about readiness. In 10 Bullets, Sachs states that knolling prepares the studio for the next burst of creativity. In software, a "clean" codebase is one that is ready for change.

• Agility: A "knolled" codebase (high cohesion, low coupling, test coverage) can be refactored or extended quickly. A messy codebase is rigid and fragile. Therefore, knolling is the technical prerequisite for Agile development.  
• Mental Health: There is a "euphoric calm" associated with order. Working in a chaotic codebase triggers anxiety and the "Zeigarnik Effect" (the brain's tendency to dwell on incomplete tasks). Knolling provides closure and a sense of control, which is essential for preventing burnout in a high-stress profession.  

9.2 The "Shadow Side" of Knolling

Is it possible to over-knoll? Yes.

• Productive Procrastination: There is a danger where "organizing" becomes a way to avoid "doing." "Knolling your kiln makes almost no sense". If a developer spends all day configuring their Vimrc or refactoring code that works perfectly well and won't be touched again, they are engaging in "Yak Shaving".  
• Obsession: For some, the desire for visual symmetry can override pragmatism. The goal of ABK is to facilitate work, not to create a museum piece. The "Scan" step is crucial here: one must assess if the organization is actually adding value.  

9.3 The Future: AI as the Ultimate Knoller

As Artificial Intelligence enters the workflow, the nature of knolling is changing.

• Automated Refactoring: AI agents are becoming capable of "knolling" codebases automatically—identifying dead code, grouping related logic, and formatting files without human intervention.  
• AI Interpretation: Interestingly, AI models (LLMs) themselves benefit from knolled code. Clear structure, consistent naming, and high cohesion make it easier for an AI to "read" the codebase and generate accurate suggestions. "Knolling" is thus becoming an optimization strategy for AI-assisted development.

10. Conclusion

"Always Be Knolling" is more than a catchy phrase borrowed from the art world; it is a unifying theory of software craftsmanship. It connects the microscopic actions of indentation and naming to the macroscopic concerns of architecture and technical debt.

By Scanning the environment, the developer maintains observability and awareness. By Putting Away the unused, they reduce entropy and security risks. By Grouping the related, they build coherent, modular architectures. By Aligning the work, they facilitate collaboration and reduce cognitive load.

In an industry defined by intangible complexity, ABK offers a tangible framework for order. It reminds the engineer that the quality of the work is inextricably linked to the quality of the environment in which it is produced. To write great software, one must first clear the bench.

Always Be Knolling.