Engineering for the worst classroom

Most software is designed in the condition where it works best: a new laptop, fast internet, a quiet room, one patient user. FitForm had to be designed for the opposite — a school hall at the end of the day, with sunlight behind the student, a four-year-old tablet, a shared connection and twenty people shouting. An engineer who builds for the good case ships a demo. An engineer who builds for the bad case ships something a school can actually use.

Light is the first enemy. A camera exposes for the brightest part of the picture, so a student standing in front of a window becomes a silhouette, and a model that cannot see limbs cannot find joints. No amount of code changes the physics, so the application does two other things: it checks the average brightness and the confidence of the landmarks in the first seconds, and it asks the student to turn around rather than letting them train and lose. A warning that arrives before the attempt is help; the same warning afterwards is an excuse.

The second enemy is the device. On an old tablet the pose model may deliver twelve frames a second instead of thirty. Every rule that counts time must therefore be written in seconds, never in frames — a mistake that is easy to make and that produces a counter which is generous on slow devices and strict on fast ones. The team found exactly that bug by replaying recorded coordinate files at several frame rates and checking that the same movement produced the same number. Tests like these are cheap, run in a second, and are the only reason anyone can trust a figure on the league table.

The third enemy is the network. School internet fails, usually at the worst moment. The expensive part of FitForm already runs offline, so a session can be completed with no connection at all; the result waits in the browser and is sent when the connection returns. The interface says which state it is in, because software that silently loses a student's work teaches them not to use it again.

Then there are people. Some students will try to cheat — shaking the camera, bouncing quickly without reaching depth, or holding the tablet and nodding. Each of these is answered by a rule rather than by a lecture: a minimum time per repetition, a required change of angle at the lowest point, and a limit on how many scoring sessions count each day. The rules are published, which matters more than their exact values, because a game whose rules are secret feels unfair even when it is not.

Underneath all of this is a principle with an unglamorous name: graceful degradation. The question is never "does it work?" but "what happens when this part does not?" If the model loads slowly, the student sees a progress message, not a blank screen. If the camera is refused, the page explains how to allow it and offers a manual entry that is marked as unverified. If the server is down, scores wait. If a landmark is uncertain, it is ignored. Each of these is a small decision; together they are the difference between a prototype and a product.

None of it is visible when the application works, which is the point. The measure of this kind of engineering is not how impressive the good session looks, but how boring the bad one feels: a student in poor light, on an old tablet, with no internet, still finishes, still sees a number they believe, and still comes back tomorrow.