Planning is a rule engine, not a calendar

A bus fleet's weekly plan was made on paper: which driver takes which bus on which day, who rests, who is owed a weekend. The rules were written nowhere; they lived in the planner's head.

It does not look like a software problem: "just put it in Excel" seems enough. But the problem is not producing a plan, it is knowing the plan obeys the rules.

Making the rules data

Constraints live in their own table: consecutive working days, minimum rest between shifts, weekend distribution. The planner reads the table, produces the plan and validates before writing.

• A new rule = a row plus a check. The algorithm is untouched.
• A breach is caught while producing the plan, not noticed in the office.
• Two different rule sets can be tried on the same fleet.

Keeping the UI thin

Most of the 326 tests run against the planner, not the window. The UI has seven screens and is deliberately dumb: it shows data and forwards commands. Because rules can be verified without opening a screen, tests stay fast and stable.

The delivery format is a decision too

Output is Excel. The office does not adopt new tools; it wants the workbook it already knows. I write it with a closed XML library, same column names. Adoption cost is zero, the formatting adapter is mine to maintain.

The cost

Because rules are data, the plan is only as good as the rule set. Forget a rule and the plan is wrong without anyone noticing — it still looks "valid". That is why adding a rule is the same job as adding a test: done separately, the failure is silent.