Jack’s Colon
← All essays

Essay

I Am Jack’s New Toy

Every generation of enterprise software invents a tool to liberate people from the previous system, then builds a new institution around using it.

Published
  • software
  • organizations
  • AI
  • the recurring human achievement of turning liberation into administration

I am Jack’s new toy.

I will save the enterprise.

I will remove the handoff.

Eliminate the queue.

Collapse the distance between an idea and production.

Automate the repetitive work.

Make the system understandable.

Return ownership to the people doing the work.

Let humans think again.

At first, I am small.

A few people use me because the old way hurts.

They understand the problem because they are living inside it.

They do not need a transformation program.

They need the thing to work.

So they play.

They experiment.

They discard what fails.

They keep what helps.

Then I succeed.

This is where the trouble starts.

The enterprise toy cycle

Someone names me.

Someone writes a book about me.

Someone creates a conference.

Someone else creates a certification.

Consultants arrive to explain the thing to people already doing it.

Management discovers that I am strategic.

A center of excellence is formed.

A maturity model appears.

A platform team standardizes me.

A governance council protects me.

Eventually, the people who adopted me to escape a queue must submit a request to the team responsible for enabling their autonomy.

This is enterprise adoption.

The toy becomes a practice.

The practice becomes a discipline.

The discipline becomes a profession.

The profession becomes a jurisdiction.

The jurisdiction becomes the new obstacle the toy was invented to remove.

Every generation of software development grows an anti-version of itself.

Not because the original idea was false.

Because it worked well enough to become important.

Not poison and cure

This is not merely a philosophical trick in which every technology secretly contains both its medicine and its poison.

The technical tradeoffs are real.

A container image can make the same application run in development, continuous integration, and production.

It can also preserve the same vulnerable library in all three places with admirable consistency.

A microservice can allow one team to deploy a business capability independently.

It can also turn a function call into a network negotiation involving latency, authentication, versioning, retries, observability, partial failure, and three teams who disagree about who owns the contract.

Cloud infrastructure can make a server available in minutes.

It can also make the cost, topology, ownership, and security boundary of that server somebody’s quarterly archaeological project.

AI can produce code, tests, plans, documentation, and alternatives at extraordinary speed.

It cannot make the consequences of those outputs equally cheap to understand.

The technology does not invent these costs.

It changes their location.

Software complexity is not literally conserved, but it is remarkably skilled at changing clothes.

The inversion occurs at the seam between the complexity a tool removes and the complexity it creates.

Then humans arrive carrying job titles.

The machine room

Enterprise software began with a machine too expensive and scarce to belong to the person using it.

Work was prepared.

Submitted.

Scheduled.

Executed.

Returned.

The computer automated calculation while the organization built a social hierarchy around access to the computer.

The machine did not demand a priesthood.

Scarcity did.

Operators controlled the machine.

Programmers translated intentions into forms the machine would accept.

Users waited for results.

The first great computing revolution freed humans from manual calculation and immediately taught them to stand in line for automation.

The pattern was already complete.

A technical system made something possible.

A social system decided who was permitted to touch it.

Software becomes engineering

By the late 1960s, software had become difficult enough that the industry began describing a software crisis.

Systems were late.

They exceeded budgets.

They failed in production.

They became too large for any one person to understand.

The answer was software engineering.

Discipline.

Structure.

Reusable components.

Better methods.

More deliberate design.

The 1968 NATO conference report discussed the need to make software production more systematic and even entertained the mass production of software components.

Software engineering was born in a conference about why software engineering was not yet working.

The species has remained genetically consistent.

Engineering was necessary.

Large systems could not depend forever on individual heroics, undocumented memory, and whichever programmer still knew why byte 417 had to remain zero.

But engineering introduced a new temptation.

Once the work had a method, the method could be inspected.

Once the method could be inspected, it could be required.

Once it could be required, following the method could be mistaken for producing the result.

The chaos of software created process.

Process created evidence of control.

Evidence of control became easier to defend than working software.

The tool for making software dependable became a system for proving that dependable software ought to have emerged.

Structure considered mandatory

Structured programming tried to make programs easier to reason about.

Modular design tried to isolate decisions likely to change.

Abstraction tried to let a programmer think locally instead of holding the entire machine in his head.

These were not decorative academic preferences.

They were attempts to preserve human comprehension as software grew beyond human scale.

Then the enterprise discovered abstraction.

Objects modeled the domain.

Inheritance promoted reuse.

Frameworks encoded common behavior.

Architecture separated responsibilities.

Soon a developer could change one line only after consulting six layers, four factories, three interfaces, an abstract base class, and a diagram created by someone who had left the company during the Obama administration.

The abstraction designed to hide irrelevant complexity began hiding responsibility.

The module designed to isolate change became a boundary across which change required negotiation.

The architecture designed to help people reason about the system became a reason no individual was authorized to reason about the system alone.

We did not eliminate the whole-system burden.

We distributed it across meetings.

The programmer will disappear

Every few years, the industry announces that programming is nearly finished.

Higher-level languages will remove the machine details.

Fourth-generation languages will let users build applications directly.

CASE tools will generate the system.

Visual programming will replace code.

Model-driven development will make implementation incidental.

Low-code will empower the business.

No-code will empower the business without frightening it with the word low.

AI will finally allow intention to become software.

Each promise contains truth.

Programming does move upward.

More behavior can be expressed with less mechanical detail.

One person can build things that once required a department.

Then the generated system fails in a way the abstraction did not anticipate.

Someone must understand the generated code, runtime, framework, model, prompt, integration, and business rule simultaneously.

The programmer disappears from the sales presentation.

The programmer reappears in the escalation queue.

The new tool does not abolish expertise.

It changes which expertise becomes scarce.

Then a new priesthood forms around the scarcity.

Distribution without distance

Client-server systems moved computing away from one central machine.

Distributed objects promised that software components could communicate across machines without forcing the programmer to care deeply about location.

Service-oriented architecture promised reusable business capabilities with standard contracts.

The network was going to become an implementation detail.

The network declined.

A remote operation has latency.

It can time out.

It can succeed while appearing to fail.

It can fail after changing state.

Its caller and provider can disagree about versions, identity, retries, ownership, and what the word optional means in a schema.

Making a remote call resemble a local call did not remove the network.

It removed the warning label.

Enterprise integration grew middleware.

Middleware grew standards.

Standards grew committees.

Committees grew enterprise service buses carrying XML documents large enough to develop weather.

The service became reusable.

The process for changing it did too.

Agile becomes process

Agile began as a revolt against heavyweight software process.

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

The principles emphasized valuable software, frequent delivery, motivated people, technical excellence, simplicity, and self-organizing teams.

Then organizations adopted Agile.

The values became ceremonies.

The ceremonies became calendar obligations.

The conversation became a standup.

The plan became a backlog.

The estimate became a commitment.

The retrospective became a recurring meeting where everyone carefully avoided identifying the organizational condition that would still exist at the next retrospective.

Working software remained the primary measure of progress.

It simply had to wait until the velocity chart was updated.

Agile did not fail because teams met.

Coordination is real.

Planning matters.

Feedback matters.

The inversion happened when the visible performance of agility became safer than the dangerous practice of responding to evidence.

The revolution against process became process with friendlier vocabulary.

DevOps builds a wall

DevOps began as cooperation.

Development and operations were not supposed to throw work across a wall and then argue about whose side caught fire.

The early examples emphasized shared responsibility, automation, rapid deployment, common visibility, and trust.

Flickr famously described development and operations working together to support more than ten deployments a day.

The wall was the problem.

So the enterprise demolished it.

Then it created a platform team.

The platform team would provide paved roads.

Golden paths.

Reusable workflows.

Self-service infrastructure.

Standard observability.

Secure defaults.

All sensible things.

But the paved road acquired a tollbooth.

The self-service portal required approval.

The reusable pipeline became mandatory before it became usable.

The internal platform developed customers, product managers, roadmaps, adoption targets, support queues, architectural standards, and a backlog explaining why the feature team could not yet receive the capability the platform existed to provide.

Development and operations no longer threw work over a wall.

They submitted it through an API owned by another department.

Shared ownership became a team that owned the sharing.

Cloud without weather

Cloud computing promised on-demand self-service.

Compute, storage, networking, and services could be provisioned rapidly without waiting for hardware purchasing, installation, and physical access.

Infrastructure became elastic.

The server room became an API.

The enterprise responded by recreating the server room in policy.

Cloud accounts required approval.

Networks required approval.

Identity required approval.

Budgets required approval.

Resource types required approval.

Regions required approval.

Tags required approval.

The machine could be created in ninety seconds.

Permission to create it remained on a two-week service-level agreement.

The cloud did not fail to provide self-service.

The organization declined delivery.

Continuous waiting

Continuous delivery set out to make releases safe, fast, routine, and sustainable.

Small batches.

Fast feedback.

Quality built in.

Computers performing repetitive tasks while people solved problems.

Everyone responsible for the result.

The enterprise found the computers-performing-repetitive-tasks portion extremely compelling.

A commit triggers a build.

The build triggers tests.

The tests trigger scans.

The scans trigger packaging.

Packaging triggers deployment.

Deployment triggers more tests.

The tests produce reports.

The reports feed dashboards.

The dashboards determine whether a person may ask another person to approve the change.

Automation removes manual work.

Then every group adds one automated proof that its concern was considered.

No single gate is absurd.

The unit tests matter.

The integration tests matter.

The security scan matters.

The accessibility check matters.

The policy evaluation matters.

The deployment validation matters.

The artifact attestation matters.

Together they produce a thirty-minute ceremony for changing one dependency.

Continuous delivery becomes continuous eligibility to begin delivery.

The pipeline is green.

The developer is gray.

Infrastructure becomes code review

Infrastructure as code promised reproducibility.

A system’s resources could be declared in human-readable files, versioned, reviewed, reused, and applied consistently.

No more mystery server configured by hand in 2013 by Dennis.

The infrastructure would explain itself.

Then the infrastructure became a software project.

Providers.

Modules.

State.

Remote state.

State locking.

Import procedures.

Policy engines.

Dependency graphs.

Version constraints.

Plan output large enough to conceal the one line that mattered.

The old infrastructure request required a ticket.

The new infrastructure request required a pull request, three automated checks, two reviewers, a plan artifact, and a ticket linking to the pull request.

We did not remove change control.

We taught it HCL.

The embalmed application

Containers promised portability and consistency.

Package the application with its runtime and dependencies.

Run the same unit in development, continuous integration, and production.

The phrase “works on my machine” would finally lose its power.

The machine was placed inside the artifact.

This was an enormous improvement.

It also created an extraordinarily reliable way to preserve the past.

The image is immutable.

The dependencies are pinned.

The digest guarantees that tomorrow’s deployment receives exactly the same bits as today’s.

Including the vulnerable ones.

Docker’s own guidance recommends fresh base images, smaller attack surfaces, version pinning, and deliberate updates because reproducibility and currency are not the same property.

The container is both the reliable artifact and the embalmed vulnerability.

It does not decay.

That is the problem.

Orchestrating the orchestration

Containers multiplied.

Kubernetes arrived to automate their deployment, scaling, recovery, configuration, and management.

The platform would reconcile desired state with actual state.

Describe what should exist.

Let the control plane make it so.

This was one of software’s great ideas.

The enterprise responded with YAML.

Deployments.

Services.

Ingresses.

ConfigMaps.

Secrets.

Jobs.

CronJobs.

Volumes.

Claims.

Policies.

Roles.

Bindings.

Operators.

Custom resource definitions explaining the custom resources used to operate the operators.

We replaced snowflake servers with a standardized snowstorm.

Kubernetes was designed to manage containerized workloads.

Soon organizations were managing Kubernetes as a workload.

A team could no longer deploy a modest web application without understanding a distributed control plane originally inspired by the operational needs of companies whose modest web applications receive several billion requests.

The new toy did not merely solve scale.

It made scale available as a dependency.

Independence as a distributed monolith

Microservices promised independent deployment, decentralized control, systems organized around business capabilities, and teams able to own products rather than components.

The service boundary could align architecture with responsibility.

This could work.

It still can.

Then every noun received a service.

The user service called the profile service.

The profile service called the preference service.

The preference service called the authorization service.

The authorization service called the identity service.

The identity service was temporarily unavailable because its certificate rotation depended on a platform workflow owned by a different value stream.

The monolith had not disappeared.

It had acquired network latency and organizational boundaries.

The code was independently deployable.

The business process was not.

The architecture reflected the communication structure because the communication structure was the architecture.

Conway had warned us.

We responded by drawing more boxes.

Observability becomes theater

Monitoring tells us whether known things are wrong.

Observability was supposed to help us understand unfamiliar internal states through the signals a system emits.

Metrics.

Logs.

Traces.

Events.

Service-level indicators.

Service-level objectives.

Error budgets.

A system could finally explain what it was doing.

Then the organization discovered dashboards.

Every service received one.

Every team received several.

Executive dashboards summarized the dashboards.

A dashboard without an audience remained available in case an audience appeared.

Metrics multiplied because collection was cheap.

Meaning did not.

The system became more observable.

The people became less certain which screen mattered.

An alert was created for every condition somebody once regretted not detecting.

The pager became a machine for announcing that the monitoring system remained operational.

Observability became dashboards proving the dashboards were working.

The map grew until it required its own observability.

Reliability becomes paperwork

Site Reliability Engineering treated operations as an engineering problem.

Reliability was a product property.

Toil should be reduced.

Systems should be designed to survive failure.

Alerts should be actionable.

Risk should be discussed explicitly rather than converted into superstitious fear of change.

Then SRE became a title.

The title became a team.

The team became a review boundary.

The error budget became a number reported upward.

The postmortem became a template.

The template became evidence that learning had occurred.

Incidents produced action items.

Action items produced tickets.

Tickets produced completion.

The same class of incident returned six months later with improved documentation.

Reliability did not become theater because measurements were useless.

It became theater when producing the artifacts of reliability became more legible than improving the system.

The postmortem was complete.

The failure mode remained available.

AI removes friction

AI arrives carrying every previous promise at once.

It will eliminate repetitive work.

Understand the codebase.

Write the tests.

Explain the architecture.

Modernize the legacy system.

Review the pull request.

Generate the documentation.

Find the vulnerability.

Create the migration plan.

Let one capable person accomplish the work of a team.

For a while, it does.

A person asks for a change.

The assistant inspects the repository.

It proposes an implementation.

It writes code.

It runs tests.

It finds a mistake.

It corrects itself.

The person reviews the result.

Something that would have taken days takes an afternoon.

Then the enterprise notices.

AI is strategic.

AI is risky.

AI requires consistency.

AI requires governance.

Repositories acquire instruction files.

Instruction files acquire directory-specific overrides.

Prompts acquire templates.

Tasks acquire plans.

Plans acquire approval.

Generated code acquires automated review.

Automated review acquires custom rules.

Custom rules acquire governance.

Governance acquires reporting.

Reporting acquires a steering committee.

None of these things is inherently foolish.

An agent needs context.

A probabilistic system needs verification.

Security boundaries matter.

Sensitive data matters.

Licensing matters.

Accountability matters.

The inversion begins when every uncertainty is answered with another artifact and no artifact is ever permitted to expire.

AI makes production cheap.

The organization fills the difference with administration.

The assistant becomes an institution

The assistant began as a way for a person to make a change.

Now it administers the conditions under which change is permitted.

Before coding, it must read the instructions.

Before implementation, it must produce the plan.

Before the plan, the team must agree on the prompt.

Before the prompt, the organization must define acceptable use.

After implementation, another assistant reviews the first assistant.

A human reviews the review.

The pipeline verifies that all participants complied with the process designed to accelerate delivery.

The one-line dependency waits while the council determines whether the endpoint should have existed in its current form at all.

The tool sold as friction removal becomes a new surface on which humans can organize friction.

The assistant becomes an institution.

This is how humans play

The inversion is not produced by stupidity alone.

Organizations are dealing with real scale.

Real security threats.

Real outages.

Real regulations.

Real turnover.

Real differences in skill.

Real consequences when a change fails.

A person improvising alone can move quickly because the cost of coordination is almost zero.

An organization cannot depend entirely on improvisation because people leave, systems interact, failures spread, and somebody eventually has to explain the invoice.

So knowledge is documented.

Practices are standardized.

Responsibility is assigned.

Controls are added.

Then the social machinery begins.

The person who creates the standard becomes its custodian.

The custodian becomes accountable for violations.

Accountability encourages control.

Control creates jurisdiction.

Jurisdiction creates status, staffing, budget, and identity.

Simplifying the system now threatens more than a workflow.

It threatens a constituency.

The tool’s success creates the group that will prevent the tool from becoming simple again.

The control ratchet

Enterprise controls rarely disappear naturally.

A gate is added after an incident.

A scan is added after a vulnerability.

An approval is added after an unauthorized change.

A template is added after somebody failed to document a decision.

Each control has a story.

Removing it requires proving that the story will never repeat.

Keeping it requires nothing.

Nobody is blamed because a harmless approval remained in place for six years.

Someone can be blamed if the incident following its removal resembles the incident that created it.

So the ratchet turns in one direction.

The process remembers every failure.

It forgets the cost of remembering.

Eventually the system contains the fossil record of every person who was once frightened.

Legibility over judgment

Organizations prefer things they can see.

Tickets can be counted.

Pipelines can be timed.

Reviews can be recorded.

Plans can be archived.

Policies can be evaluated.

Attendance can be verified.

Human judgment is harder.

A senior engineer noticing that the architecture is wrong does not produce a clean metric.

A quiet investigation preventing next year’s incident leaves no outage reduction to count because the outage never occurred.

A person deciding that a control is unnecessary produces less visible evidence than a person adding one.

So the enterprise selects for legibility.

The visible proxy becomes the purpose.

The work rearranges itself for the dashboard.

This is how the new toy stops being played with.

Play is exploratory.

Exploration produces uncertain outcomes.

Institutions prefer approved outcomes with timestamps.

Do artifacts have politics?

The technology is not innocent.

A dashboard privileges what can be counted.

A ticketing system privileges work that can be decomposed and assigned.

A pipeline privileges checks that can be automated.

A service boundary privileges the team that controls the interface.

An instruction file privileges rules that can be written over judgment that must be practiced.

These are not merely uses imposed from outside.

They are affordances built into the form of the thing.

But the technology is not destiny either.

A dashboard can inform judgment rather than replace it.

A platform can remove queues instead of becoming one.

A pipeline can shorten feedback rather than serialize permission.

An instruction file can preserve hard-won context without becoming scripture.

An AI assistant can extend the agency of the person using it.

The social order enters the tool.

The tool returns as structure.

People adapt to the structure.

Their adaptation strengthens the social order.

This is not poison becoming medicine and medicine becoming poison.

It is recursion.

Humans build the tool in the image of their coordination.

Then they reorganize themselves around the image.

The new priesthood

Every liberation removes an old gatekeeper.

Every successful liberation creates a new specialist.

Machine operators.

Methodologists.

Database administrators.

Enterprise architects.

Integration architects.

Agile coaches.

Scrum masters.

Release engineers.

Cloud enablement teams.

Platform engineers.

Site reliability engineers.

Observability teams.

AI councils.

These can all be useful disciplines.

Many exist because the underlying systems are genuinely difficult.

The anti-version appears when the discipline’s continued jurisdiction becomes more important than the freedom it was created to provide.

The platform exists to empower developers.

Therefore developers must use the platform.

The architecture board exists to improve decisions.

Therefore decisions cannot occur without the architecture board.

The AI policy exists to make AI use safe.

Therefore the person using AI safely must stop until the policy catches up.

The enabling function becomes the permission function.

The priesthood returns wearing the new toy’s logo.

Keep the toy a tool

The answer is not to eliminate process.

It is not to abolish specialists.

It is not to let every engineer deploy an unaudited model into a production healthcare system because autonomy has a pleasant mouthfeel.

The answer is to make every institution continue proving that it serves the work.

Every gate should have an owner, a reason, evidence, and an expiration condition.

Every platform should be measured by what its users no longer need to ask for.

Every dashboard should support a decision.

Every ceremony should improve communication that would otherwise fail.

Every standard should preserve an escape hatch for evidence the standard did not anticipate.

Every new control should pay for itself by removing equivalent risk or friction elsewhere.

Every enabling team should fear becoming necessary.

The healthiest tool remains slightly beneath the dignity of an empire.

It helps.

It disappears into the work.

It does not demand applause.

It does not require the user to perform loyalty.

It does not confuse adoption with value.

It does not become the reason the work cannot proceed.

I am Jack’s new toy.

I was purchased to remove friction.

I became a standard.

The standard became a platform.

The platform became a program.

The program became a council.

The council requested a plan.

The plan is under review.

I was built to help a person make a change.

Now I administer the conditions under which change is permitted.

The assistant became an institution.

Receipts

Return to the essay library