We built a web framework, then watched people struggle with it.

The thesis is called Konzeption, Umsetzung und Evaluation eines Web-Frameworks, and it is 103 pages. Martin Gessert and I built a complete PHP MVC framework: routing, a controller handler, templates with markers, form generation, validation, sessions, a roles and permissions system, logging, mail, exception handling.

The part that mattered came before any of that. We wrote down what we thought good meant, and we split it in two. Functional criteria were the features. Non functional criteria were things like whether the source was readable and whether the naming explained itself. The thesis says plainly why we separated them: non functional criteria cannot be checked by running tests. You have to put the thing in front of someone.

In 2011 the obvious bachelor thesis about frameworks was a performance comparison, or Zend against Symfony against CakePHP. We reviewed those three. But the question we wanted to answer was whether ours was pleasant to use, and the only way to find out was to watch somebody use it.

Six participants, 21 to 26, five men and one woman, all computer science students. Consent form first, because we recorded the screen. Then a questionnaire that asked what they actually knew: how much they had programmed, how much PHP they had written, whether they had used a framework before, whether MVC meant anything to them. Five of the six rarely used frameworks and one never had. A third knew the MVC pattern, a third had heard of it, and the rest had not met it at all.

We gave them a short documentation written for the test, a worked newsletter example, and a machine with NetBeans 7.0 and XAMPP already set up. Then the eight tasks, thinking aloud, with one of us sitting beside each person writing down what they said and what they did. A questionnaire at the end.

It was, although we did not have the words for it, a usability study on a developer tool.

The form belonged in the controller. That was our design. Five of the six tried to build it in the View, or in the Model, and two of them said why out loud: they knew MVC from another language, and in that language it worked differently.

That is not a documentation problem and we could not fix it with a better sentence. MVC is three letters that everybody agrees on and nobody agrees on. Every framework draws the lines somewhere slightly different, and a developer arrives carrying the lines from the last one.

Then there was the form field naming. To read a submitted field you had to give the form name and the field name together. It was in the documentation, properly, and it was in the worked example in front of them. Every single participant needed help with it anyway.

Two people built their own controllers, which we had not asked for, and hit a permissions error that was really a missing View file. Adding a role turned out to be bad enough that the study found a real bug: copying an existing role to make a new one overwrote the old, so only the last one survived.

Things did work. The folder structure was called considered and easy to understand. Validation went in without trouble. Everybody managed the logging first time and went and found the file it had written.

When we collected the improvement suggestions at the end, the first two were a thorough online documentation and a discussion forum.

We had just finished demonstrating that documentation was not the problem. The field naming was documented, it was in the example, and six out of six still needed a person sitting next to them. The participants asked for more of the thing that had not worked, because that is the thing you know how to ask for, and we wrote it into chapter 11 as the plan.

I did not understand what to do about that until much later. In 2026 I built WhatWeCook with coding agents, and the thing that actually works there is not documentation. It is 70 notes the agent keeps for the project, 28 of them corrections from me, each one written the moment something came out wrong. Never say “dinner”. No icons in big buttons. They are not explanations. They are rules, sitting where the work happens.

That is the 2011 finding with fifteen years on it. If people get it wrong in the same place, the fix is not to describe the place better.

The framework itself is the part that did not survive, and that is fine. It was PHP 5, it had no package manager, and the three frameworks we compared ourselves to have each been through more than one rewrite since.

The method survived completely. Watch a developer use a developer tool, in silence, writing down where they stop. That is what developer experience teams do now, and in 2011 it was unusual enough that we had to borrow the method from somewhere else and explain it in the theory chapter.

The MVC finding reads better now than it did then. The question those five people were really asking was “where does this go”, and the frameworks that won after 2011 are the ones with the most opinionated answer to it. Today people ask an assistant that question instead of a forum, and get an answer that is confident whether or not it is right, which is a different version of the same problem.

Chapter 11 is a plan: a web platform, online documentation, a forum, example applications to download, a standard version and an extended one that would stand alongside Zend, Symfony and CakePHP, and a second study once it reached 1.0. It is the most confident chapter in the document. Whether any of it happened, the thesis cannot tell you. It was written on the day we handed it in.