Whether to move off QuickBooks is not a technology question. It is a spend decision with a return you can calculate, and the person who signs the close is the one who should own it. The trap is treating it as a preference — a nicer interface, a newer vendor — when it is really a threshold problem. Below the threshold, QuickBooks plus discipline is the right, cheap answer. Above it, staying costs more every month than moving would, and the cost hides in labor and risk instead of on an invoice.
So the useful question isn’t “is QuickBooks good enough?” It’s “what is the status quo actually costing us, and has that number crossed the line yet?” Everything below is about finding that line.
These are the patterns that separate a real ceiling from a setup you configured badly. One of them alone rarely justifies a migration. Two or three together usually do.
Here is the framing that turns this from opinion into arithmetic. The cost of staying is real; it’s just unbilled. Put a dollar figure on three lines and the decision usually makes itself.
Add those up as an annual number. That’s your cost of inaction. It is the honest thing to weigh a migration against — not the QuickBooks subscription, which was never the expensive part.
A migration is a real project with a real budget, and anyone who quotes you a fixed price before seeing your data is guessing. Think in ranges across three buckets:
The timeline that governs the budget: a mid-market Enterprise Resource Planning (ERP) implementation typically runs about five to seven months from decision to go-live, and that assumes someone internal can own it without dropping their day job. The largest hidden cost of the whole project is that person’s time — the months your best operator spends on migration instead of running the business. It sinks more projects than the sticker price does. We work these numbers as scoped ranges, never a fixed quote, and you should be suspicious of anyone who does otherwise.
Before you evaluate a single platform, document your own numbers. This is the deterministic part of the decision, and it comes first — you cannot compare systems against requirements you haven’t written down. Write down, on one page — the same inventory the [[Outgrowing QuickBooks: is it time for ERP?]] guide walks through step by step:
That page is worth more than any vendor demo. It’s the artifact that lets you compare platforms against your reality instead of against a sales narrative, and it’s the difference between choosing a system and being sold one.
There is no single right answer, and any advisor who leads with one before seeing your inventory is selling, not advising. Oracle NetSuite, Microsoft Dynamics 365 Business Central, and — for more companies than vendors like to admit — a well-configured QuickBooks with the spreadsheets retired are all legitimate destinations depending on entity count, inventory complexity, transaction volume, and how much internal capacity you have. The right target is whichever one your one-page inventory points to. We stay neutral on purpose and build systems you own and could leave with, because the point is a platform that fits your numbers, not a vendor you’re locked into.
If two or three of those signals are true and your cost-of-inaction number has crossed your migration number, the move is worth doing once and doing well. A scoped assessment — your one-page inventory, what you actually need, and whether to fix the model or replace it — is the cheapest way to avoid a six-figure mistake. See [[ERP consulting]] to start there.
]]>When we inventory software at small and medium businesses (SMBs), we typically find somewhere between a handful and a dozen AI tools in active use that nobody approved — free chatbot accounts, browser extensions, note-takers quietly sitting in on client calls. Each one is a place where company or client information now lives outside your control.
That exposure lands differently by industry. For a Denver law or accounting firm, a paralegal pasting a client matter into a personal chatbot account may have just stretched a confidentiality duty past its limit. For a dental clinic, patient details in a consumer AI tool are a Health Insurance Portability and Accountability Act (HIPAA) problem whether or not anything bad happens next. And on many free consumer tiers, the vendor’s terms allow your inputs to be used for model training — which means “just delete it” may not be an option later.
The instinct is to ban everything. That fails within a month: the staff who found these tools useful keep using them on personal devices, and now you carry the same exposure with zero visibility. The policy that works gives people a sanctioned way to do what they were already doing.
A workable SMB policy fits on one page and answers three questions.
What’s allowed without asking. Drafting and editing internal documents and emails. Summarizing meeting notes and public information. Writing or reviewing code in company repositories. Brainstorming and research starting points. All of it on approved tools under company business accounts — business tiers generally offer admin controls and contract terms that exclude your data from training, which free tiers may not.
What’s banned without written approval. Client-identifying or client-confidential information. Employee, payroll, or health records. Passwords, keys, and security configurations. Personal AI accounts for any company work. And the big one: sending AI output to a client, court, or regulator without a named human reviewing it first.
What gets logged. Which tools are approved and who holds the accounts. Who reviewed AI-assisted work before it left the building. And for material decisions — pricing, hiring, anything that touches the books — the tool, the prompt, the output, and the reviewer.
If you want a framework behind those choices, the National Institute of Standards and Technology’s (NIST) AI Risk Management Framework is the reference we use. In plain terms it asks for four things: govern (someone owns the policy), map (know where AI is actually used), measure (check the outputs), and manage (fix what the checks find). A one-page policy, a tool inventory, and a quarterly review cover all four at SMB scale.
Adapt the brackets, delete what doesn’t apply, and resist the urge to add legal boilerplate. A policy nobody reads is a policy nobody follows.
AI acceptable-use policy — [Company name]
Effective [date] | Owner: [name, role] | Reviewed: quarterly
1. Approved tools
- [Tool A] under the company business account only
- [Tool B] under the company business account only
- Anything else requires written approval from [owner/role]
2. Allowed without asking
- Drafting and editing internal documents, emails, and marketing copy
- Summarizing meeting notes and publicly available information
- Writing or reviewing code in company repositories
- Brainstorming, research starting points, and format conversion
3. Prohibited without written approval
- Entering client-identifying or client-confidential information
- Entering employee records, payroll data, or health information
- Entering passwords, keys, or security configurations
- Using personal AI accounts for any company work
- Sending AI output to a client, court, or regulator without a
named human reviewing and approving it first
4. Review and logging
- AI-assisted work that leaves the company gets a human review;
the reviewer is accountable for the content
- [Owner/role] maintains the list of approved tools and accounts
- Material decisions supported by AI (pricing, hiring, financial
reporting) are logged: tool, prompt, output, reviewer, date
5. When in doubt
- Ask [owner/role] before pasting. Asking is never a violation.
For most firms this size, the whole cycle is 2–4 weeks of part-time effort, and most of it is conversation rather than paperwork.
The policy is the paper half; the working half is the tool inventory, the business-account setup, and the guardrails that make the rules stick. That’s the first working session in [[AI solutions and intelligent automation]] — and it usually surfaces the riskiest paste before the policy is even final.
]]>A few years ago, a small and medium business (SMB) cyber application was a page of yes/no questions. Today it’s a multi-page attestation, and your answers do three jobs at once: they set your premium, they set your exclusions, and they become evidence if you ever file a claim. An answer you guessed at — “sure, we have multi-factor on everything” — can void coverage at the exact moment you need it, because carriers investigate the attestation after an incident, not before.
Four controls carry most of the weight: multi-factor authentication, endpoint detection, backups, and offboarding. They also happen to track closely with the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Cyber Essentials guidance, which is a useful free reference whether or not an insurer is asking.
Multi-factor authentication (MFA) means a second proof of identity beyond the password. The application will ask about it on email, on remote access, on administrator accounts, and increasingly on the backup console itself — because attackers who get in like to delete the backups first.
How it moves the number: for many carriers, “no” here isn’t a surcharge, it’s a declination or a ransomware exclusion. The good news is that MFA is usually the cheapest control on the list — on Microsoft 365 or Google Workspace it’s configuration work, not new spending.
Endpoint detection and response (EDR) watches behavior on laptops and servers — a process encrypting files at 2 a.m., a login from nowhere — and can isolate a machine automatically. That’s different from legacy antivirus, which checks files against a list of known bad ones. Applications now ask for the product by name and what percentage of devices it covers.
How it moves the number: weak answers here tend to show up less in the base premium and more in the fine print — higher retentions (your deductible) and lower ransomware sub-limits.
The application asks three things: do you back up the systems that matter, is at least one copy offline or immutable (meaning the same attacker who encrypted your network can’t encrypt it too), and have you actually tested a restore. A backup that lives on the same network with the same credentials as everything else counts as no. So does a backup that has never been restored — until it’s tested, it’s a hope, not a control.
How it moves the number: tested, separated backups shorten downtime, and downtime is most of what the insurer is pricing.
How quickly are accounts disabled when someone leaves? Are there shared logins? Do former employees or contractors still have live credentials to email, remote access, or the accounting system? Stale accounts are one of the cheapest ways into a network, and carriers know it. For a multi-location retailer or a construction firm with seasonal field staff, this question deserves more attention than it usually gets.
Ranges, because that’s what’s honest: SMB cyber premiums commonly run from the low four figures to the low five figures per year depending on revenue, industry, and limits. The four controls above largely decide which market you shop in. A documented yes on all four puts you in the standard market with competitive quotes. A no — or a “partially,” which carriers read as no — typically means some combination of higher retention, a ransomware sub-limit, an exclusion, or a push into surplus-market pricing that can run a multiple of standard. The premium is the visible cost; the exclusions are the expensive one.
Do this before the broker’s deadline, not the night of.
If the self-audit produced more “partially” than you’d like, closing exactly these four gaps — and producing the documentation that lets you answer the application honestly — is standard scope for [[Managed IT services]]. Bring the application; it makes a very good project plan.
]]>AI is moving into the finance function at small and medium businesses (SMBs) through the side door: proposing general ledger (GL) codes for bank-feed transactions, drafting reconciliations, estimating accruals, writing collections emails. All useful. But finance has a century-old discipline for actions that touch the books — every journal entry carries who, what, when, a source document, and an approval — and AI actions in those same workflows carry none of that by default.
A vendor’s chat history is not an audit trail. It lives on the vendor’s retention schedule, in an account you may not control, in a format you can’t hand to an auditor. Meanwhile, financial records are typically retained for around seven years. If an AI-proposed categorization flows into an entry your auditor questions in year three, “the conversation expired” is not a working answer.
The control frameworks don’t carve out software, either. The Committee of Sponsoring Organizations of the Treadway Commission’s Internal Control — Integrated Framework expects control activities and reliable information regardless of which actor performs a step. An AI proposing entries is a preparer. Preparers generate evidence.
Treat every AI touch of a financial workflow like a journal entry. The mapping is direct:
| Evidence on a journal entry | Equivalent for an AI action |
|---|---|
| Preparer | Staff member who ran it, plus the model and version used |
| Date | Timestamp of the run |
| Amounts and accounts | The output, verbatim — proposed codes, numbers, or draft text |
| Source document | The exact input snapshot: the bank-feed export, the invoice batch |
| Approval | Named reviewer, their decision, and the date |
If you can produce those five fields for any AI-assisted step, you have a control. If you can’t, you have a very fast, very confident preparer working off the books.
None of these questions are exotic — they’re the standard questions asked about any preparer. The only new part is that the preparer is software.
Walking into fieldwork with a register that answers all five is the difference between AI reading as a well-controlled efficiency and AI reading as a scope expansion.
For a typical SMB finance team, standing this up takes 2–4 weeks of part-time effort. Week one is scoping: list every place AI currently touches a financial workflow — the inventory is usually longer than the controller expects. Week two, define the register and the preparer/approver split for the highest-volume touchpoint, which is almost always bank-feed categorization. Weeks three and four, run it live, tune the exception process, and fold the rules into your broader AI use policy so the register’s scope and [[An AI acceptable-use policy your team will actually follow]] agree on what counts as touching the books.
This is the finance-literate side of AI adoption, and it’s where a dual accounting-and-systems background earns its keep. If AI is already drafting entries somewhere in your close, see our [[Finance tech]] — accounting systems and controls that hold up under audit.
]]>You can feel it the first time an agent reads your repo, forms a plan, runs your test suite, and hands you a diff — all from a request you typed where ls used to go. The shell stopped being a dumb pipe to the kernel and started behaving like an operating system in its own right: scheduling work, holding context, remembering what you told it last week, deciding which tools to call. I’ve started calling that composite bashos — not a product you install, but the posture the command line is taking on as artificial intelligence (AI) moves into it.
This is a field guide to that shift, written for people who already live in a terminal. The good news and the bad news are the same sentence: the thing coming for your job is also the best tool you’ve ever been handed. Learning to tell those two apart — and then to ride the one that’s left — is the whole new trade.
A while back I argued that [[Prompts are the new command line]] — that the interface for getting work out of a machine had moved from syntax you memorize to intent you describe. That was the first half of the story. The second half is what the terminal does after it understands you.
An operating system, stripped to its job description, does a handful of things: it schedules work, manages memory, keeps track of context, brokers access to tools and devices, and enforces who is allowed to do what. Look at what a modern terminal agent does and the list is eerily familiar. It schedules a sequence of steps. It manages a context window like a working set, paging facts in and out. It remembers project conventions across sessions. It decides which command-line tool to reach for. It (should) ask before it touches anything dangerous. The shell has quietly acquired the responsibilities of a kernel — except the thing it schedules isn’t CPU time, it’s intent.
Make it concrete. Last year, “rotate the logging config across the fleet and confirm nothing broke” was a morning: Secure Shell (SSH) into box after box, edit files, grep for errors, eyeball the dashboards. The bashos version is one sentence of intent, after which an agent drafts the change, runs it against a staging box, diffs the before-and-after, and reports what moved — and you spend your morning deciding whether it was right, not typing it. The work didn’t vanish. It changed shape, from doing to directing.
This isn’t a metaphor I’m straining to make fit. As of mid-2026 the terminal-agent category is the fastest-moving corner of the developer-tools market, and the field is crowded: Claude Code, Gemini CLI, OpenAI’s Codex CLI, OpenCode, Aider, Warp, Goose, and Amazon Q Developer CLI all run the same core loop — read your project, plan, execute in your shell, show you the result. Microsoft announced an Intelligent Terminal at Build 2026: a separate, opt-in build of Windows Terminal that pipes your shell context to whichever agent you bolt on — Copilot, Claude Code, Codex, Gemini — over a local Agent Client Protocol. And in the research world, projects like AIOS have gone the literal distance and put a large language model where the kernel scheduler used to sit, complete with agent scheduling, memory management, and tool-access control.
Put those together and the trend line is clear. The command line is no longer just a way to issue instructions to an operating system. It’s becoming one.
Here’s the part nobody on a vendor stage will say plainly: the same capability is both the threat and the tool, and there is no version of the future where you get one without the other.
Start with the threat, because pretending it isn’t there ages badly. A large share of traditional systems-administration work is exactly the kind of bounded, well-documented toil that an agent eats for breakfast. Provisioning, log triage, writing the same firewall rule for the hundredth time, turning a ticket into a three-line script: that used to be the moat. The moat is now a one-liner you hand to a process that doesn’t sleep, doesn’t get bored, and costs less per hour than your coffee. Technical skills date faster than they used to, and the specific keystrokes you’re proud of have a shorter shelf life than your laptop.
Now the other face of the same beast. The practitioners who actually fold AI into their workflow get real hours back — the ones that used to vanish into rote work — and demonstrable AI fluency is starting to separate otherwise-identical résumés. Engineering organizations running terminal agents at scale report shipping faster and reclaiming meaningful capacity. The threat and the tool are not two things. They are one thing, viewed from two sides of your own willingness to use it.
That’s what makes the competition your best friend-enemy. You cannot out-type the agent; it’s faster. You cannot out-remember it; it holds the whole repo in context. What you can do — the only durable move — is out-judge it: decide what’s worth doing, catch it when it’s confidently wrong, and own the outcome when it ships. Beating the beast and harnessing the beast turn out to be the same maneuver. You befriend it, you point it, and you stay the one holding the leash.
The old loop was simple and human-bound: you think of a command, you type it, the machine runs it, you read the output, repeat. Every cycle went through your fingers. That ceiling — your typing speed and your recall — was the real constraint on a sysadmin’s throughput for forty years.
The new loop breaks the ceiling by taking your fingers out of the inner cycle. You state an intent. The agent drafts a plan. It executes in a sandbox. It shows you a diff or a dry-run. You review, correct, approve. You own the result. Notice what moved: you are no longer the operator of the machine. You are the orchestrator of something that operates the machine for you.
Which is to say you’ve been promoted into the kernel. Every responsibility an agent operating system has to handle, a human now handles one level up:
That is the literal job spec of an operating-system kernel, now running on you. The phrase that keeps rattling around my head is operating systems built into them — and it cuts both ways. The AI has an operating system built into it. And the professionals who thrive build an operating system into themselves: a disciplined internal model for how to dispatch, constrain, and verify a fleet of tireless, fallible workers. The trade isn’t disappearing. It’s moving up the stack, from the keyboard to the control room.
Enough theory. If bashos is the terrain, here is how to actually work it — the practices that separate people getting real leverage from people generating impressive-looking nonsense at scale.
The instinct is to tool-hop — a new command-line interface (CLI) every week, chasing benchmarks. Resist it. The leverage comes from fluency, and fluency comes from repetition. Pick one capable terminal agent, point it at real work, and stay long enough to learn its failure modes: where it over-edits, where it invents a flag, where it needs a nudge. A tool you know cold beats a marginally better tool you’re always relearning.
The single biggest predictor of whether an agent helps or hurts is what it knows going in. Give it a map. Most agents now read a project file — AGENTS.md, CLAUDE.md, a README, a runbook — on startup, and that file is one of the most valuable things in your repo now. Write down the conventions, the architecture, the do-not-touch list, the commands to build and test. Context engineering has quietly overtaken prompt cleverness as the skill that matters: a plain prompt with great context beats a brilliant prompt with none.
The cardinal discipline is plan, then diff, then commit, with a human between each step on anything that matters. Run agents in a sandbox by default — Codex CLI, for one, isolates execution so it can install packages and run tests without touching your real environment. Dry-run destructive operations. Never let an agent push to production, drop a table, or rm -rf unattended. The cost of reading a diff is seconds; the cost of an unreviewed agent action against prod is your weekend, or your job.
There’s a quiet lesson coming out of teams running these agents in anger: feeding an agent a pile of giant, chatty integrations is often worse than letting it call small, composable command-line tools. The token cost alone is lopsided — a focused CLI call can be a couple of orders of magnitude cheaper than the equivalent fat-protocol round trip — and the behavior is more predictable. The Unix philosophy did not die when the AI showed up; it got a new customer. An agent that pipes grep, jq, gh, and kubectl together runs circles around one drowning in context it can’t use.
The senior engineer’s real value was never the keystrokes — it was the judgment encoded in their muscle memory and their home-directory aliases. Externalize it. Turn a runbook into a prompt. Turn a good prompt into a saved slash-command or a skill. Turn a recurring workflow into a scheduled agent that runs at 6am and leaves you a report. Each step converts something locked in one person’s head into an asset the whole team — and the agents — can run the same way every time. This is the modern Makefile, and it compounds.
A useful mental model: the agent is a brilliant, fast, oddly confident junior who has somehow been handed root. You would not let that person operate without guardrails, and you delegate to them without abdicating to them. Give the agent its own identity, not your god-credentials — the platforms are moving toward exactly this, issuing agents their own scoped identity and audit trail. Least privilege, secrets out of prompts, log everything it does. In a world where everyone has the same models, your security posture is the differentiator that doesn’t commoditize.
An agent will hand you a wrong answer with the same cheerful confidence as a right one. The defense is to make verification cheap and automatic: tests, linters, type-checkers, and continuous integration (CI) are no longer hygiene — they’re the seatbelt that lets you drive fast. The teams getting the most out of agents are, paradoxically, the ones with the strictest automated checks, because strong verification is what makes it safe to delegate aggressively. Trust the beast exactly as far as your test suite can throw it.
The great irony: AI in the terminal makes deep systems knowledge more valuable, not less. You cannot review a plan you don’t understand. You cannot catch a confidently wrong networking change if you don’t know how the network works. The professional who only knew the keystrokes is the one the agent replaces; the one who knows why becomes the indispensable reviewer of last resort. Keep reading man pages. Keep learning how the kernel, the filesystem, and the protocols actually behave. That knowledge is what you trade on now — your edge isn’t speed anymore, it’s correctness.
You don’t master this by reading about it. Pick one agent. Point it at a real repository you already understand — not a toy — and give it a genuine task: write the tests for a module, draft the runbook, refactor the ugly function. Write the AGENTS.md while you’re in there. Then read every diff before you accept it, and notice where it was brilliant and where it lied. Do that for a week and you’ll have a more honest sense of the beast than any blog post — including this one — can give you.
In the spirit of practicing what it preaches, this piece was built the way it describes working. The research — the current state of terminal agents, the Microsoft Intelligent Terminal, the shape of the workforce shift — was gathered by an AI agent fanning out across sources, then checked against more than one of them before any claim made it in. The structure was drafted, argued with, and rewritten. The judgment about what’s true, what’s overstated, and what’s worth saying stayed human. That’s the loop in miniature: let the beast do the fetching and the first draft; keep the deciding for yourself. A few things that made it work, and that generalize:
That’s bashos in one paragraph: the machine got faster, and the part that’s still your job got more important.
The quest was never to beat the beast. It was to become the kind of professional the beast makes more valuable instead of less — the one holding the leash, reading the diff, owning the call. bashos isn’t something you download. It’s something you become.
$ supervise "the beast" &
[1] running
$ # the prompt comes back. what you do with the freedom is the whole job.
The competition really is your best friend-enemy. So make friends — and keep your hand on the leash.
And if you’re working out where terminal agents fit in your own shop — what to hand them, what to gate, and what to keep human — that’s the conversation behind our [[AI solutions and intelligent automation]].
]]>The Model Context Protocol (MCP) is an open standard for connecting AI assistants to outside systems — file shares, databases, business applications. It was originally developed by Anthropic and is now openly published, with the specification and documentation at modelcontextprotocol.io.
The plainest way to think about it: before the Universal Serial Bus (USB), every device needed its own cable and its own port. MCP does for AI-to-system connections what USB did for peripherals — one standard plug instead of a custom cable per pairing.
There are two halves. The assistant side speaks the protocol. On the system side, a small adapter called an MCP server sits in front of each system and exposes a short menu of named operations — “search the policy folder,” “look up ticket status,” “read the AR export” — each with defined inputs and outputs. The assistant can only order off that menu. That constraint is the whole point.
Until recently, wiring an assistant into your file share or ticketing system meant a custom integration — the kind of project that gets quoted in weeks of development time and never gets funded at small and medium business (SMB) scale. A standard changes the economics. Adapters are small and reusable, vendors increasingly ship their own, and the work shifts from building plumbing to deciding permissions — which is where an owner’s attention belongs anyway. For the back-office wiring described below, that’s typically days of configuration and guardrail design rather than a custom development project.
The value isn’t in exotic new systems. It’s in the ones you already run.
Here’s the framing that keeps these projects safe. A language model is probabilistic: the same question can produce two different answers. Your general ledger, your job-costing system, and your ticket queue are deterministic: the same query returns the same record every time. Good architecture keeps the facts in the deterministic systems and the judgment in the model.
MCP enforces that split at the connector. Each tool the server exposes is a defined operation against a system of record — the assistant decides which tool to call and how to phrase the answer, but the number comes from the export and the ticket status comes from the queue. The model can’t invent an operation you didn’t expose. When a wrong answer would cost money, the thing that prevents it is a permission, not a clever prompt. This is the same trust discipline we laid out in [[Prompts are the new command line]], pushed down into the plumbing.
If there’s a copy-paste ritual in your back office that an assistant with two or three tightly scoped connections would end, that’s a well-bounded first project. See how we scope this kind of work in [[AI solutions and intelligent automation]].
]]>One long brittle pipe— a single stage coughs, the whole morning runs to null.
Here is the automation everyone writes first. It is a straight line. It reads like a sentence and it dies like one.
$ fetch | clean | enrich | score | route | notify | log | archive
Eight stages, seven pipes, one direction. It feels efficient because it looks efficient — no branching, no loops, no ceremony, just data falling downhill from left to right. You ship it. It runs beautifully for nine days. On the tenth, enrich times out against a third-party application programming interface (API) at 6 a.m., and because a Unix pipeline is only as alive as its narrowest dead stage, everything downstream of enrich receives an empty stream and dutifully processes nothing. score scores nothing. route routes nothing. notify notifies no one that nothing happened. By the time you look, the whole morning has run cleanly to null and reported success, because exit code 0 is the most dangerous lie in computing.
The straight line is brittle for a reason that has nothing to do with this particular API. It’s brittle because it has no way to correct itself. Data goes in one end and out the other, and nowhere in that geometry is there a path for the output to inform the input. A line is not a system. A line is a hope with stages.
The fix is not more stages. The fix is a shape. And the shape, it turns out, is almost always a triangle — because three is the magic number, and I mean that structurally, not mystically.
Two legs and it tips, four legs rock on uneven floors—three sits dead still.
Bob Dorough sang it in 1973 — a man and a woman had a little baby, yes they did, there were three in the family, that’s a magic number — and a generation learned multiplication from a cartoon that was, underneath the harmony, making a claim about structure. Three is not magic because it’s lucky. Three is magic because it’s the first number that holds.
Watch a three-legged stool on a stone floor. It never wobbles. It cannot wobble, because three points define exactly one plane, and any three points — however uneven the floor — sit flush against the single plane they define. A four-legged chair on the same floor rocks, because four points over-define the plane and the floor gets a vote. This is why surveyors use tripods, why your camera mount has three legs, why the milking stool has survived ten thousand years of furniture innovation unchanged. Three is the minimum that is also the maximum: the fewest supports that guarantee stability, and one more than that buys you nothing but a rock.
Now look at the triangle itself. In structural engineering the triangle is the only rigid polygon. Push on the corner of a square frame and it collapses into a rhombus — the angles give, the shape folds flat. Push on the corner of a triangle and nothing moves, because to change a triangle’s shape you’d have to change the length of a side, and the sides are members under tension and compression, not hinges. This is the entire reason bridges, cranes, roof trusses, transmission towers, and geodesic domes are built from triangles and not squares. The triangle distributes load to its corners and refuses to deform. Squares need diagonal bracing to survive — and a diagonal brace is just a confession that you wanted a triangle all along.
So when I tell you to build automation in threes, I am not invoking the rule of comedy or the three acts of a screenplay, though those rhyme. I am telling you that three is the smallest count of things that produces a structure instead of a pile. Two oscillates. Four wobbles. Three holds load.
Wind dead on the bow— you cannot sail straight; you tack a triangle home.
Here is the part that feels wrong until you’ve lived it: the most efficient route to a goal is often not the straight line at it.
A sailboat cannot sail directly into the wind. Point the bow at the thing you want when the thing you want is upwind, and you stop dead, sails luffing, going nowhere with great conviction. The efficient path to a point you cannot approach head-on is a triangle — you tack, sailing at an angle off the wind on one leg, then crossing to the opposite angle on the next, and the zigzag, which looks like a detour to anyone who’s never held a tiller, gets you there when the straight line gets you nothing. The triangle isn’t the scenic route. The triangle is the only route, and it is faster than the straight line that doesn’t move.
Mathematicians have a name for the deep version of this: the triangle inequality. For any three points, the direct side is never longer than the sum of the other two — d(A,C) ≤ d(A,B) + d(B,C). It sounds like a tautology and it is the foundation of every routing optimizer ever written. It’s why a logistics planner reaches for a milk-run loop — depot to A to B to C and home — instead of driving out and back, out and back, out and back, three separate round trips from the depot. Each leg of the loop is never longer than the detour back through the depot would be, so the loop that touches three points in sequence beats the star that returns to center between each one. Triangulate the route and you stop paying for the trip home you take three times.
And the same geometry runs the wall you plugged this laptop into. The electrical grid does not deliver power as one wire doing its best. It delivers three-phase power: three alternating currents, each offset by 120 degrees — a third of a cycle — so that as one phase troughs, another peaks, and the sum delivers smooth, constant power with no dead spots. One phase pulses. Two phases still leave gaps. Three phases, spaced a third of a circle apart, hand the motor a continuous push and use less copper doing it. Every industrial motor on Earth runs on the discovery that three rotating things, evenly offset, never all rest at once.
That is what a good automation loop is. Not a line — a triangle of three nodes, each handing off to the next, the third feeding back to the first. You already know the shapes, because the disciplines that survived all converged on the same three-node loop and gave it different names:
Notice what each of these has that the straight pipe didn’t: the third node points back at the first. Act changes the world that Sense reads. Learn rewrites what you Build. The triangle closes. That closure is the difference between a system that corrects itself and a sentence that runs to null at 6 a.m. and tells you it succeeded.
#!/usr/bin/env bash
# Not a pipe. A loop with three vertices and a way home.
while true; do
state=$(sense) # read the world
action=$(decide "$state") # choose, given the reading
apply "$action" # change the world
sleep "$INTERVAL" # ...and sense the world you just changed
done
Two nodes — sense and act, no decide — and you get a relay that slams on and off, oscillating, because nothing mediates. Four nodes and you’ve added a vertex that someone will eventually have to explain to a new hire, and which will be the one that’s subtly out of phase. Three nodes hold load.
Mind holds three at most— break the mountain into three stones you can lift now.
A loop needs something to loop over, and this is where most automation dies a second, quieter death: the chunk is the wrong size.
Human working memory holds about three to four items at once — the number has shrunk in the literature since George Miller’s famous “seven, plus or minus two,” and the honest modern figure is closer to four, often three under load. You do not overcome that ceiling by trying harder. You overcome it by chunking: grouping the raw material into a handful of units each small enough to hold whole. A phone number is ten digits you can’t retain and three chunks you can. A goal is the same. “Migrate the platform” is a mountain you cannot lift and cannot even see the top of. “Stand up the new database, dual-write to both for a week, cut reads over” is three stones, and you can pick up the first one today.
Machines have the same constraint wearing different clothes. In [[work & play & dev &: job control for the sleep-deprived]], the lesson was that dev — the deep-work process — only makes progress in long uninterrupted blocks because it needs its whole working set resident and the cache hot; starve it of a contiguous slice and it produces nothing but guilt. Chunking is how you size work to the slice you can actually give it. Too big a chunk and the job can’t fit in one focused block, so it never completes and never checkpoints — it just thrashes, paging your attention to disk. Too small a chunk and you drown in overhead: the cost isn’t the work, it’s the context switch between the pieces, and a thousand tiny pieces means a thousand switches, each taxed.
The right chunk is the one you can carry through the loop exactly once — sense it, decide on it, act on it — before you have to set it down. And the elegant part, the part that closes the loop back to the triangle, is that the best chunking is also in threes. Break the goal into three. Break each of those into three. You descend a tree where every node has three children, and a tree of depth three already has twenty-seven leaves — enough granularity to schedule real work, shallow enough that you can still see the root from the leaf. Divide and conquer is the oldest algorithm we have, and it does not divide into eleven. It halves, or it thirds, and the thirds tend to map better onto the way a goal actually has a beginning, a middle, and a done.
# A goal you can't hold:
deploy_the_whole_thing
# Chunked into a loop you can run, three at a time:
for stone in stand_up_db dual_write cut_over; do
result=$(run_chunk "$stone") || { rollback "$stone"; break; }
checkpoint "$stone" "$result" # set it down before you pick up the next
done
Three stones. Each one small enough to lift, run through the loop once, and set down with a checkpoint — so that when enrich times out at 6 a.m., you lose one stone, not the morning.
Five, seven, then five— the small fast core reads the work, routes it, steps aside.
A haiku is three lines: five syllables, seven, five. It is the smallest poem that still completes a thought — short enough to hold whole in working memory, structured enough to have a shape, and built, of course, on three. The form survived a thousand years for the same reason the milking stool did: it is the minimum that holds. Every epigraph above this paragraph has been one, and you read each of them in a single slice without strain. That is not decoration. That is the chunk size of the human mind, set to verse.
There is a haiku of trade, too — the smallest complete transaction, the three-beat loop at the bottom of all commerce. A request comes in. A decision is made. A response goes out. Read the order, decide the fulfillment, ship the thing. Five-seven-five. Sense, decide, act. It is the same triangle wearing an apron, and for the whole history of business it had a human at the front of it: someone who read what came in, judged what it was, and routed it onward — the clerk, the dispatcher, the desk that triaged the morning’s mail into piles.
That front seat is now an artificial intelligence (AI) core. And here is the actual news, the thing under your brief: it is not the biggest model that takes the front. It’s the smallest fast one.
The pattern has a name in the trade now — the router, or the cascade — and the economics are the triangle inequality applied to compute. You do not send every request to the most powerful, most expensive model you own, any more than you’d drive a separate round trip from the depot for every single package. You put a small, fast, cheap model at the front — call it a Haiku, because that is precisely the role and, as it happens, the name of the model class built for it — and its whole job is the first beat of the loop: read the work, decide what it is, and route it. Most requests are simple, and the fast front-line core handles them whole and ships the answer in one slice. The genuinely hard ones — the cases where the triangle inequality says the detour through heavier compute actually pays — it escalates: hands them up to the heavyweight, the deep reasoner, or out to the human who’s the right one of the three to lift this particular stone. The fast core reads the work, routes it, and steps aside.
# The haiku of trade, with an AI core at the front.
classify=$(haiku "triage: $request") # the fast front-line read — line one
case "$classify" in
simple) haiku "resolve: $request" ;; # ...handles it whole, ships it
hard) opus "resolve: $request" ;; # ...escalates to the heavyweight
human) queue_for_human "$request" ;; # ...or routes to the right person
esac
# Front core fronts. All else follows what it sends.
This is the inversion worth sitting with. The instinct is to put your most capable thing at the front of the operation — the senior engineer reads every ticket, the biggest model sees every prompt, the partner takes every call. It’s backwards, and it’s backwards for a reason you now have the geometry to see. The front of a loop is the sensing node, and sensing wants to be fast, cheap, and constant — three offset phases handing off a smooth signal, not one enormous pulse with dead spots between. You want the heavy capability held in reserve for the chunk that genuinely earns it, the way you hold dev’s deep block for the work that needs the whole cache hot. Put the fast core in front to triage and route, and the expensive capability stops being a bottleneck and becomes an escalation path. The Haiku takes the front. All else follows what it sends.
Which means the entire performance of the system now rides on a thing it never used to: the quality of the routing. When a small fast core sits at the front of the trade and everything downstream follows its read, a bad triage doesn’t fail loudly — it succeeds, confidently, at the wrong thing, and runs your morning to null while reporting exit 0. The clerk who mis-sorts the mail mis-sorts it fast and at scale. So the discipline shifts from doing the work to checking the front — auditing what the router escalates and what it doesn’t, watching the cases it waves through, keeping the human in the loop precisely at the vertex where the fast core decides who lifts the stone. The automation didn’t remove the judgment. It moved it to the front and made it the only thing that matters.
Haiku takes the front; all else follows what it sends— earn what comes behind.
You will keep wanting to build the straight line. It reads so cleanly left to right, and the shape of a sentence is the shape of how we think a task should go: this, then this, then this, then done. But a line has no way home. It cannot correct what it got wrong because nothing in its geometry points backward, and so the first dead stage runs the rest of it to null and tells you it worked.
Three is the magic number, and the magic is structural. So, three things to take with you — because of course there are three:
Build the loop, not the line. Three nodes, the third pointing back at the first. Sense, decide, act, and sense the world you just changed. The triangle is the only shape that holds load, and a loop that closes is the only automation that corrects itself.
Chunk the goal until it fits in one slice. Three stones, each small enough to carry through the loop once and set down with a checkpoint. The right chunk size is the one that survives an interruption without losing the morning. When in doubt, third it.
Put the fast core at the front. The haiku of trade now has an AI core reading the first line — small, fast, constant — routing most of the work whole and escalating only the chunk that earns the heavyweight or the human. That’s the efficient shape. But the front is now the whole game: all else follows what it sends, so audit the read, watch what it waves through, and make sure what comes behind is worth the follow.
The trade has a new clerk at the front desk, and it works in fives and sevens and fives, sorting the morning’s mail faster than any human ever could. For a Denver small or medium business (SMB), that is the difference between two analysts hand-triaging support tickets all morning and a small model routing most of them — often 70–85% — in seconds, freeing your people for the harder fraction that actually needs a human. That’s not the end of your job. That’s the start of a better one — minding the vertex where the fast core decides, because everything downstream is now following a haiku, and a haiku is only as good as its first line.
$ exit 0 # this time, on purpose.
At BASH Consulting we build the automation that holds — loops that correct themselves, goals chunked to a size your team can actually carry, and AI cores placed where they make the system faster instead of where they make the demo flashier. If your pipeline is a straight line quietly running to null at 6 a.m., see how our [[Software development]] work puts the right shape — and the right model — at the front.
Every technologist has, at some low point, typed the equivalent of this into the universe and hit Enter:
$ work & play & dev &
[1] 24601
[2] 24602
[3] 24603
$
Three jobs. One ampersand each. All backgrounded, all running at once, prompt returned instantly, hands free. You lean back. You will earn a living, be a whole person, and finally ship the side project — concurrently, like a real machine. The dream of every overcommitted human is the same dream Unix sold us in 1973: throw an & on the end and walk away.
Then jobs reports the truth.
$ jobs
[1] Running work &
[2]- Stopped play
[3]+ Running (eating all memory) dev &
play is Stopped. It’s always Stopped. And somewhere off-screen, a fourth process you did not schedule is about to fork into the foreground and seize the terminal with a priority you are not authorized to override.
Let’s talk about job control.
Here is the lie at the center of modern adult life: that you are running these things in parallel. You are not. You have one core. One. A single execution unit doing what single cores have always done — time-slicing so fast it produces the convincing illusion of simultaneity. The central processing unit (CPU) you bought in 2019 fakes multitasking by switching between processes thousands of times a second. You fake it by answering a Slack message at a playground.
The catch is the context switch. When a real CPU switches processes it has to dump the registers, flush part of the cache, load the next process’s state, and warm everything back up. It’s cheap in silicon and ruinous in wetware. When you switch from dev to work to “why is the toddler quiet,” you pay a context-switch tax measured not in nanoseconds but in the time it takes to remember what the function you were writing was supposed to return. The often-cited University of California, Irvine study on workplace interruptions found it takes people an average of about 23 minutes to return to an interrupted task. Your scheduler is running at maybe forty productive minutes an hour, and that’s on a good day with no SIGCHLD storm. (We’ll get to SIGCHLD.)
So the goal was never true parallelism. It was a tolerable time-slicing policy. Most of us are running the worst one available: switch on every interrupt, prioritize whatever screamed loudest, and let the lowest-priority job starve.
jobs -l: meet the processesBefore you can schedule three jobs you should know their resource profiles, because they do not behave alike.
work is the daemon that pays for the electricity. It launches at boot whether you want it to or not, it has a habit of quietly raising its own priority — it starts the day at a polite nice 0 and by 4 p.m. it’s somehow renice’d itself to -5 and is preempting everything — and it refuses to die on logout. You close the laptop; work keeps running, because some prior version of you ran it with nohup:
$ nohup work &
work: ignoring input and appending output to 'nohup.out'
nohup means “no hangup” — the process survives the terminal closing. That’s the technical name for the email that finds you at 9:47 p.m. It is immune to the hangup signal by design. You did this to yourself.
dev is the fun one and the dangerous one. It’s your daemon, the thing you actually chose — the side project, the homelab, the repo nobody asked for. It is also a memory hog that only makes progress in long uninterrupted blocks. dev does not time-slice gracefully. You cannot give it ninety seconds between other tasks and expect output; it needs the cache hot and the whole working set resident, which is exactly the condition your life is least able to provide. When dev gets starved, it doesn’t crash — it just sits there as a process you keep meaning to bring back to the foreground, accruing guilt instead of commits.
play is the process with the highest nice value in the system — nice 19, maximum niceness, which in the wonderful inversion of Unix means lowest priority. The nicer the process, the more readily it yields the CPU to everything else. play is so polite it never demands anything, which is precisely why it never runs. It is Stopped in your jobs list right now. Hold that thought, because the kernel has plans for it.
Now the part nobody benchmarks for.
At some point you run fork(). The child process spins up. And every assumption your scheduler made goes out the window, because this is not a job you can background.
A forked child inherits the parent’s environment. This is true in Unix and it is true in the kitchen — the child gets a copy of your environment variables, your habits, your exported defaults, the way you say the word you wish you didn’t say. export PATIENCE=thin and watch it propagate.
But the real engineering problem is signals. In Unix, when a child process stops or terminates, the kernel sends the parent a signal called — and I want to be clear that I am not making this up — SIGCHLD. The child literally signals the parent. A toddler is a process that fires SIGCHLD at unpredictable intervals, demanding the parent immediately stop what it’s doing and handle it, and if the parent ignores the signal the child does not get cleaned up and the situation only gets worse. You end up writing a signal handler:
trap 'handle_snack_request' SIGCHLD
And here is where job control breaks down completely:
child &. It runs in the foreground by divine right and holds the terminal.nohup it. It does not survive you leaving the room; it follows you, signaling.renice it. It runs at nice -20, the maximum negative niceness, the highest priority the system allows — and on a real Unix box, setting a priority that aggressive requires root. You are not root. You filed the request and were denied. The toddler is root.kill -9 it. kill -9 sends SIGKILL, the one signal a process cannot catch, block, or ignore — the nuclear option that always works. It does not work here. It is the one place in all of computing where kill -9 is off the table, and thank goodness, but operationally: your hardest preemption tool has been removed from the rack.So now your jobs list looks like this:
$ jobs
[1] Running work &
[2]- Stopped play
[3] Stopped dev
[4]+ Running (foreground) child # nice -20, uninterruptible, owns the terminal
dev got bumped to Stopped to make room. Of course it did.
The naive response is to oversubscribe — keep all four “running,” background everything you can, and push harder. This is where you meet the two failure modes every overloaded system shares with every overloaded parent.
The first is swap. When a machine runs out of random-access memory (RAM) it starts paging memory out to disk, and if it’s doing that constantly it enters a state called thrashing: it spends so much effort moving pages back and forth that it does almost no actual work. The load average climbs, every process slows, and the box is technically up but accomplishing nothing. The human version is a Tuesday where you were busy for fourteen hours and shipped not one thing. You were thrashing. You were paging your attention to disk.
The second is the zombie. In Unix a zombie is a child process that has finished executing but whose parent never called wait() to read its exit status — so it lingers in the process table, done but un-reaped. Your life is full of zombies: the laundry that is technically washed but will never be folded, the pull request (PR) that’s approved but un-merged, the email you’ve read and mentally answered and not actually sent. Each one holds a slot. Enough un-reaped tasks and you run out of entries in the table, and the strange thing about zombies is you can’t kill them — they’re already dead. You have to reap them. The only fix is to finish the thing you already finished.
Meanwhile the parent, having not slept, has become a different kind of zombie entirely. The metaphor, like the laundry, does not fold cleanly.
playWhen memory pressure gets bad enough that swap can’t save it, the Linux kernel deploys its last resort: the OOM killer. It walks the process list, scores each one on a heuristic of how much it’d reclaim and how expendable it looks, and it kills the loser to keep the system alive. (If you want the gory scoring details, the kernel documents the oom_score_adj tunable in /proc.)
You already know which process it picks. It is never work — work pays for the RAM. It is never child — child is nice -20 and untouchable. It is dev, and when dev is already Stopped, it is play. The OOM killer comes for play first, every single time, because play is the most expendable-looking thing in the table. It made itself maximally nice. It never demanded a slice. And so the system, doing exactly what it was configured to do, reaps the one process whose entire purpose was to make running the others bearable.
This is the actual bug. Not that there are too many jobs. That the scheduler is configured to starve the one job you cannot articulate a business case for.
The fix is not a productivity system. It’s a scheduling policy, and the good ones share a few properties.
Stop pretending you’re parallel. work & play & dev & is a lie your prompt tells you. You time-slice; the only question is whether you do it on purpose. Run one job in the foreground at a time and let it actually own the core. A focused hour on dev beats four hours of dev getting SIGCHLD‘d every nine minutes — because of the context-switch tax, those are not the same four hours.
cron the non-negotiables. The recurring, load-bearing events should not depend on you having spare attention to schedule them. Bedtime, the standing date, the gym, daycare pickup — these go in crontab, they fire on a timer, and they are not subject to renegotiation by whichever process is loudest at 5 p.m. A cron job doesn’t ask permission. That’s the feature.
# m h dom mon dow command
0 18 * * 1-5 run play --no-laptop # weekdays, 6pm, non-negotiable
0 21 * * * reap_zombies # fold the laundry you already washed
Batch your context switches. The cost isn’t the work, it’s the switch. Answer work in two or three deliberate windows, not continuously. Every time you fg and bg between jobs on a whim you pay the tax twice.
Give play a guaranteed slice and protect it from the OOM killer. This is the whole point. The process with no business case is the one keeping the box alive; reserve CPU for it explicitly, the way you’d pin a critical service so the kernel can’t reap it. If play only runs on the scraps left after work and dev and child, it runs never, and then the other three degrade too, because they were always running on play’s output without admitting it.
Let dev detach. This is what tmux and screen are for — a session that keeps running after you disconnect and is sitting exactly where you left it when you reattach. dev cannot demand a four-hour block from a life that contains a nice -20 child. But it can survive interruption if you stop expecting to hold its whole state in your head and start letting the session hold it for you. Write the failing test before you stand up. Leave a // TODO: you were here at the cursor. Reattach, don’t restart.
And handle the one interrupt that’s worth it synchronously. Here’s the turn. Everything above is about defending your jobs from interruption — except one. The child process is the single workload in the whole system where stopping the foreground task to handle the signal is the task. You will spend a number of years being interrupted by it, and the cruel math is that the interruptions feel like the thing keeping you from your real work, right up until the window closes and you understand they were the workload the entire time. work will fork new instances of itself forever. dev will still compile in a decade. The nice -20 child downgrades to nice 5, then nice 10, then forks a process of its own and stops sending you SIGCHLD at all, and you would give a kidney to get one more.
So: protect play. Detach dev. cron the rest. And when the small process signals, handle it in the foreground, on purpose, without resentment. That’s not a failure of your scheduler. On a good day, that is the scheduler.
Strip the parenting jokes and this is the scheduler running most small businesses we walk into. There’s a work daemon that renice’s itself to -5 and eats every interrupt — the loudest customer, the squeakiest invoice, the integration that broke this morning. There’s a dev job that never gets a focused block, so the migration off QuickBooks or the reporting cleanup sits Stopped for two years. And there’s a play process — the strategic project with no screaming deadline and no obvious business case — that the OOM killer reaps first every quarter, because nobody pinned it.
The teams that ship the strategic work are not working more hours. They’ve just stopped letting the loudest process and the kernel’s lazy default decide the schedule. They give the load-bearing project a guaranteed slice, batch the interrupts into windows, and detach the long-running work so a single interruption doesn’t cost a full restart. The fix is a policy, not a person grinding harder.
You will not run work & play & dev & in true parallel. No one does; the people who look like they do are just running a better time-slicing policy and not telling you about the swap. You have one core. You always did. The skill was never doing all of it at once — it was choosing, slice by slice, which process gets the core right now, and refusing to let the loudest one or the kernel’s lazy default decide for you.
Now if you’ll excuse me, job [4] is signaling, and this one I take in the foreground.
$ fg %4
At BASH Consulting we spend our days untangling systems that are technically running but quietly thrashing — the strategic project that’s been Stopped for two years because the loud daemons eat every slice. If your team’s scheduler keeps reaping the wrong process, see [[Software development]].
]]>It is 2026. Your Enterprise Resource Planning (ERP) vendor just announced an AI agent that predicts supply-chain disruptions before they happen. Bravo. Meanwhile, back in the fluorescent-lit cubicles of your IT team, someone is alt-tabbing between six different user interfaces from four different decades just to ship a pallet.
This is Frankenstein’s ERP: a stitched-together creature of modern browser tabs, multiple 2000s-era thick clients, and a character-based warehouse module that was probably coded during the Clinton administration. Vendors love to ignore it on the keynote slide. Your warehouse cannot.
The bill for this monster is real, and it is paid monthly. We routinely see mid-market manufacturers (roughly $200M-$500M in revenue) spending six figures a year on contractors just to keep the oldest pieces alive, plus a 28-35 person internal IT group whose actual job is “keep the green screens blinking.”
Two forces are squeezing these companies at once:
Every day spent maintaining the creature is a day not spent on the modernization the business actually wants.
Take a $400M manufacturer with plants in the US, Mexico, the UK, and India. Here is the daily dance a single user performs:
Six interfaces. Six different ways to hate your morning.
The CHUI module deserves its own spotlight. Built on Progress OpenEdge 4GL (a fourth-generation language so niche it is practically an endangered species), this green-screen relic runs the most mission-critical tasks on the floor: label printing, radio-frequency (RF) scanning, shipping, and receiving finished goods. One crash and the production line stops. It is the ERP equivalent of running your whole plant on a single 40-year-old steam valve while the vendor brags about its new electric turbine. The code is editable only through a fragile .NET-wrapped editor that crashes more often than the line it controls. This is not development. It is archaeology.
Need a bug fixed in the CHUI label routine? You had better hope your retainer with that one developer in India is still active. Progress 4GL expertise is concentrated halfway around the world, and the people who have it are guarded like nuclear codes.
A production receipt fails at 2 PM Colorado time. That is 1:30 AM in India. By the time the wizard wakes up, you have lost a shift, your inventory counts are wrong, and someone is hand-printing labels on a desktop printer like it is 1999. Lose that contractor to attrition and you are shopping in a talent market thinner than a quiet day in a warehouse.
For a $400M global manufacturer running this portfolio, the “bare minimum” IT organization looks less like a department and more like a museum staff for a live production system:
| Role category | Headcount | Unofficial job description |
|---|---|---|
| Leadership and governance | 3-4 | Professional apologizers for why nothing works together |
| Functional support | 8-10 | Translators fluent in six UI dialects and one ancient 4GL incantation |
| Technical maintenance | 6-8 plus contractors | Includes 2-3 offshore wizards who can edit the sacred 4GL scrolls |
| Infrastructure and endpoints | 5-7 | Keepers of terminal emulators, legacy printer queues, and Wi-Fi prayers |
| Service desk | 6-8 | First responders to “why does this only work in the old client?” |
| Total | 28-35 | A support group for technological trauma |
Three things sink the “we’ll just migrate to the cloud” plan, and they are worth naming before you sign anything:
The honest answer is not “rip everything out next quarter.” It is to stop treating the creature as one unmovable mass and start dismantling it in priority order.
This is the work where a finance-literate, vendor-neutral outside team earns its keep: we can read the 4GL and the general ledger, and we have no incentive to push you onto any single platform.
You do not have to keep stocking Red Bull for 3 AM calls or perfecting your “it’s a feature, not a bug” smile. The first move is a clear-eyed map of what you own and what it is costing you. See our [[ERP consulting]] for SMB and mid-market manufacturers, and we will help you decide which parts of the monster are worth saving.
For the morbidly curious who want to understand what they are actually maintaining, the Progress OpenEdge ABL reference documentation is the primary source on the language keeping your warehouse alive.
In all of this, you are not the villain. You are the punchline, at least until you decide to write a new joke.
]]>(Lights up. Frantic developers in cubicles, offshore support reps on video calls, and a giant spinning wheel labeled “Circle of Fix” looming over the stage like the Circle of Fifths but built entirely out of Jira tickets. The build has already failed. The orchestra swells.)
(to the tune of a rising perfect fifth, slightly off-key)
We shipped the code to Bangalore at night, Thought we’d wake up to features shining bright! But every patch they send comes back with flair, A brand-new bug in every layer!
Namaste, sir! Your ticket is resolved! We fixed the null by making three evolve! Please to be closing, rate us five out of five, Regression suite? We keep that barely alive!
(sung in overlapping rounds, like a fugue that never resolves)
It goes C to G to D to A, Then E fixes B which breaks yesterday! Every dominant bug spawns a subdominant twin, We modulate keys but the crashes stay in!
Round and round in the Circle of Fix, Every perfect fifth costs us sixty-six! We outsource the patch, they outsource the blame, And the circle keeps turning, it’s always the same!
I once wrote clean code in the key of C-sharp, Now I’m chasing stack traces through functions that warp. They “refactored” my function to save fourteen lines, Now it sings in twelve tones and summons daemons at runtime.
We work for one-fifth of your Silicon pay, So you get one-fifth quality, fair trade, I’d say! We fix it in React, then port it to Flask, Then wrap it in COBOL because PM asked!
“Scope is fixed, deadline is fixed, budget is fixed, Everything else is flexible!” (Beat.) “Why is nothing working?!”
Circle of Fix, modulating pain! Every tritone resolved births a bug once again! We’ll be here forever in seven-sharp hell, Pushing hotfixes nightly while stakeholders yell!
Round and round in the Circle of Fix, The bugs go marching four by four, hurrah? Hurrah? We modulate up but the quality dips, And the circle keeps spinning… (whisper) …send it to the Philippines.
“Have you tried turning it off and on again?”
It’s funny because it’s true. A lot of small and medium businesses (SMBs) in the Denver metro find themselves humming some version of this song: a feature gets built, it breaks something else, the fix gets handed to whoever is cheapest and available, and three weeks later you’re back where you started with a new bug and a thinner budget.
The wheel isn’t a vendor problem, an offshore problem, or a “bad developers” problem. It’s a process problem, and it gets very expensive very fast. The longer a defect survives before someone catches it, the more it costs to fix. A bug caught while you’re still writing the requirement is a five-minute conversation. The same bug caught in production, after a customer hits it, can cost orders of magnitude more to unwind, a relationship Barry Boehm documented decades ago and the U.S. National Institute of Standards and Technology (NIST) put hard numbers behind in its report on the economic impacts of inadequate software testing. Every loop around the Circle of Fix is you paying the late-stage price over and over.
You don’t escape the wheel by yelling at the support choir. You escape it by changing three things.
Most “the offshore team broke it” stories are really “nobody wrote down what ‘it’ was.” When the spec is a Slack message and a hope, every developer fills the gaps with a different guess, and the gaps are where bugs live.
What “good enough” looks like for an SMB:
You do not need a 40-page specification. You need enough that two different people would build the same thing.
The song’s funniest line is the truest: “We outsource the patch, they outsource the blame.” When responsibility is shared across an onshore team, an offshore team, and a product manager, it is owned by no one, and the bug just keeps getting passed around the stage.
Pick one person, internal or external, who owns each feature end to end and is accountable for it working in production. Cheaper hands on the keyboard are fine. Diffuse ownership is what kills you.
The choir’s confession, “Regression suite? We keep that barely alive,” is the whole problem in one line. Without automated tests, every fix is a coin flip on whether it quietly breaks something that used to work. That’s the literal mechanism of the wheel: E fixes B which breaks yesterday.
A practical starting point:
You don’t need 100% coverage on day one. You need a net under the 10 transactions that, if they broke, would cost you customers or a clean month-end close.
For most SMB codebases, stepping off the wheel is a phased effort, not a rewrite:
What your team has to do: name the owner, tell us which transactions actually matter to the business, and resist the urge to skip testing the next time a deadline is “fixed, fixed, and fixed.”
If your software life feels like a chord that never resolves, the fix is process, not panic. Our [[Software development]] work helps Denver SMBs put requirements, ownership, and automated testing in place so the wheel finally stops turning.
Tired of singing the same chorus on loop? Let’s help you step off the wheel.
]]>