Minnesota Code Freeze Conference Notes

My notes from the 2025 Minnesota Code Freeze conference that took place at the University of Minnesota.

Working Effectively with Legacy Code

Michael Feathers (r7k)

• Test-Driven Architecture (like TDD but for architecture).
• Hyrum's Law: Any behavior you expose on an API will become depended upon even if it's not intended.
• Knowledge tends to dissipate over time (think music popularity reduction over time, for example, the ragtime of the 1920's).
• Galileo's scaling law (the square/cube law) - structure must change as things grow:
  • Initially named after the concept that as an object grows its volume grows faster than the surface (n^3 > n^2).
  • However, applies to other scaling concerns, for example, you can't build a skyscraper with wood.
  • With graphs, as they grow, you need to break them into smaller graphs to manage them effectively.
  • Understanding this tension can improve design.
• Miller's law - humans can track 7 +/- 2 items
  • This relates to class design, a class with 20 methods is much harder to track than a class with around 7.
• "The Principle of Deliberate Context" (coined by Michael Feathers):
  • Systems should be designed with intentionally bounded contexts that are optimally sized for human cognition.
• Robustness principle: be liberal in what you accept and conservative in what you produce.
• A potential issue with AI is when it generates things that we don't understand.

Infrastructure as Code Anti-Patterns

Jason Baker (Director of Cloud Operations at Civix)

• Thought on anti-patterns: every anti-pattern started as a pattern with good intentions.
• Why do infrastructure as code anti-patterns exist?
  • Senior tech leadership usually is promoted through software not infrastructure (citation needed).
  • Defining infrastructure as code is immature compared to software development (isn't infrastructure as code software development?).

1. Cloud Cowboys

• Creating cloud infrastructure manually (using a web console) instead of using code.

1. Muti-Tool Madness

• Using too many tools to define the infrastructure.
• Increased complexity, risk, and toil.
• Picking a consistent tool is more important than pick the best tool.

1. Partitioning infrastructure projects by infrastructure type or environment instead of by context.
2. Building all the environments

• Using a single infrastructure template to build out all environments.
• Templates should be environmentally agnostic.
• Infrastructure changes should be promoted using the same process as normal software.

1. One repo to rule them all

• Defining all resources using infrastructure code in one monolithic infrastructure code repository.
• Can introduce undesirable coupling.
• Partition infrastructure code by services.

1. Using DRY With Infrastructure

• All software problems can be solved with another layer abstraction, except for the problem of too many layers of abstraction.
• Taking an imperative approach to building infrastructure instead of a declarative approach.
• Coupling vs. cohesion

1. Modularize all the things

• Same as above.
• Enforce the updating of module versions across projects, allowing no more than for example 2 versions in use.

1. The infra team

• All infrastructure code has to be defined by an infrastructure team.
• Reinforcese the traditional division between developer and infrastructure operations.
• A single team becomes a major bottleneck for infrastructure work.
• In high-performing organizations most of the infrastructure code is defined by software developers and co-located in application repositories.

1. All security related infrastructure code changes must be implemented and approved by the secuirty team.

Finite State Machines and AI

Adam Terlson (https://github.com/adamterlson/AgenticStateMachines)

• Using state machines to control AI agents.
• X State: state management and orchestration library
• Model-based testing of state machines
• His AI Agent definition:
  • Autonomous - operates independently, making decisions without constant human input
  • Goal-oriented - achieves specific objectives
  • Context-aware
  • Collaborates
  • Interactive
  • Persistence - retains memory of past interactions and data.
  • Adaptive
• Agentic Systems:
  • Actors provide autonomy and communication.
  • State machines provide structure, enforce predictable behavior.
  • AI provides adaptability.
• Patterns:
  • Tool use
    • Available tools given to LLM.
    • LLM returns JSON object describing a method (tool) call.
    • Expected next message is tool response.
  • Human in the Loop (tool approval, if tool is expensive).
  • Feedback: one oagent receives the output of another agent and gives feedback on how to improve.
  • Collaboration: multiple specialist agents working on a broader goal where each agent owns a slice of the broader task.
  • Orchestration: Planning agent dynamically routes to the next agent based on current context.
  • "Chartering": state machine defined by LLM.
• Advantages over industry tools?
  • (LangGraph and competitors)

Evolveable Architectures

Rebecca Parsons

• Conway's law - the systems you build will reflect the dysfunction of your organization.
• Last responsible moment - wait to make decisions until the last possible moment.
• How do we build code that is auditable?
• How do we build code that increases code quality?
• Contract testing allows developers to ignore each other.
• Use AI for contract testing?
• LLM hallucinations are a feature, not a bug. How are you supposed to generate something new if you never make something up? The question is whether there are ways to bound the hallucinations (yes, with temperature).
• How do you test non-deterministic systems?

Monolith vs. Platform vs. Serverless

Corwin Diamond

• This talk was generally biased against monoliths (seemed to imply a definition of a monolith as a giant legacy application, in something like an older ecommerce server application).
• CAP Theorem:
  • Consistency - works correctly.
  • Availability - always works.
  • Partition Tolerance - works across different partitions.
  • You can pick 2.
• Distributed CAP: different services/teams within your ecosystem will have different CAP requirements.
• Multi-cluster platforms...
  • Need to solve data replication.
  • Sounds like classic SOA/microservice problems.
• Cellular architecture...
  • Platform monoliths.
• Modularize abstract abstractions.
• Minimize different types of deployment processes.
• Remove requireemnts that aren't required.

Panel

David Laribee, Rebecca Parsons, Michael Feathers

• Remote work:
  • How can we maximize the effectiveness of in-person time?
  • Shoud do hybrid meetings remote first.
  • Important to work on things together with remote work.
  • Create venues where smaller collaborations can occur.
  • Times when we get together should be treated as precious and valuable.
  • Is the problem encouraging people to value social connections?
• Modular Monoliths:
  • Return to simplicity.
  • Look into testcontainers.
  • It is important at the early stages of a product development to develop a well-structured monolith.
  • Chris Richardson has good ideas on microservices.
  • Event-driven applications can be done in process (and I do).
• Functional programming:
  • "The little lisper", "the little schemer" books.
  • If one spends too much time in the OOP world, it can become difficult to understand functional programming.
  • More people are recognizing the benefits of functional programming.
• How do we discern when we should adhere to new programming principles vs traditional principles?
  • With low-code/no-code, you can get started very easily, but it's hard to scale to complex problems.
    • It's easy to solve 80% of the problem, hard to solve the remaining 20%.
  • Be very cautious about de-scaling your development.
  • Where have all the mid-level engineers gone :D.
• Is agile dead?
  • Agility was kind of jettisoned, and "agile" became a management practice.
  • Good technology (and good process?) disappear, they just become standard operating procedure, like small commits, TDD, etc.
  • There are different product domains: Simple, Complex, and Chaotic. Which domain your product fits in determines how "agile" you need to be.
• 3 things developers can do to stay current:
  • Need to start using AI.
    • How are they going to make money off of it?
  • Everyone is using AI today which differs from the prior AI hype cycles of the 60's and 80's.
    • And problematically, most people do not have a strong mental computational model that matches how it really works.
  • AI is good at ideation. It can also help increase your skill at asking questions.