There’s an old adage: “Teach them correct principles and let them govern themselves.” With that in mind, we pulled together a set of programming principles and patterns, along with proven architectural designs and some best practices. Eighteen of them, from error handling to naming conventions.
Then we stacked them up against our highest goal:
Enhance learning, especially for youth, through our IT skills and our insights to leverage tech.
Principles serve other principles
Once they were side by side, we could see that certain principles served other principles. There were lower-order principles that were needed to achieve a higher-order one.
Take error handling. It sounds like the most technical, least inspiring item on the list. But follow it up:
Error handling → problems diagnosed from the logs alone → lower IT support cost → savings that can move to the education budget → more resources for students.
A developer catching an exception properly is, a few links up, putting money back into a school. Nobody writes that on the ticket, but it’s true.
The hierarchy
Here’s how our principles stack. Each rung makes the one above it affordable.
- Foundation: clean, consistent, private data. Privacy in anything we commit, a well-modelled data hub, and consistent naming. Everything above is built on this.
- Automation. Systems do the repetitive work, not people. Data-driven design lets one engine maintain many sites or accounts from declared data, and tests and secrets management keep it safe to run unattended.
- Minimized support. When something breaks, it’s diagnosed fast and fixed once, where it starts, not patched in every system downstream.
- Scalability. One solution serves every school, and can keep upgrading. A team buried in support has nothing left to scale with.
- Acceptance. People choose to use it and use it correctly. A good interface prevents the bad data that creates support work in the first place.
- Benefits served. Time and money back to schools, and leaders who can see where to act, because the KPIs were designed into the project, not bolted on later.
One caution: read the arrows as enabling, not causing. Low support cost doesn’t cause scale. It frees the capacity to scale. Each rung is hard to reach while the one below it is unpaid for.
How close can our principles get to a student?
From our vantage point, we aren’t in direct contact with students. So how close could our principles take us?
Honestly, to the classroom door. Our principles hand off in two ways:
- Resources. Time and money that no longer go into support, re-keying and firefighting can go to students instead.
- Information. Clean data that puts the right picture in front of a principal or district leader, early enough to act.
Past that line, it’s people: teachers who know their students, principals who decide where to put a support, families who know their kids best. That’s where learning actually happens, and no principle of ours replaces it. It’s why the dashed line is on the diagram.
There’s one exception, where a principle touches students directly: privacy. No real student, parent or staff member appears in anything we commit to a repository. Not a test file, not a screenshot, not a support note. That one protects a child whether or not anything else on the ladder works.
Why bother with a hierarchy?
A flat list of eighteen standards is hard to learn and easy to ignore. A hierarchy helps in three ways:
- It’s easier to learn. A new developer, or an AI assistant, can see why each standard exists, not just what it says. “Log once with full context” is a chore. “Log once with full context so support costs less and the savings reach a classroom” is a reason.
- It settles conflicts. When two principles pull against each other, the one serving the higher rung usually wins.
- It lowers tech and support costs. The principles that cut support cost the most, and can be checked automatically, become hard gates. The rest are reviewed. Effort goes where it pays.
This is how we use the principles in SystemsCatalog: each repository is scored against them, and the gaps are fixed in an order that doesn’t force rework.
Try it with your own standards
Take any standard your team follows and ask: what does this serve? Then ask it again of the answer. If you can climb from the standard to your organization’s highest goal, you’ve found its reason, and your team will follow it more willingly. If you can’t, it may be worth questioning. It’s the same test I use for KPIs, which have to ladder up to something meaningful.
Do your principles stack? I’d like to hear how you rank yours: info@celeritysw.com.
