In one of my recent projects, we were able to experience a spookily beautiful lesson on the topic of "separating problem and solution space." I'd like to share this experience with you:
For controlling a motor and two brakes, the customer provided a specification in table format, along with a few natural language requirements. At the start of the project, this Excel document had eight worksheets describing state machines: states in columns, inputs in rows. Some of these tables required 3x4 cells, while others already contained 10x6 cells. Many boundary conditions were described via footnotes for the individual cells. So far, so good.
Over the course of the project, we repeatedly discovered inconsistencies and problems with these tables. Sometimes it turned out that the resulting engine behavior didn't meet the customer's expectations. Other times, the tables didn't represent all possible error cases.
The customer continued to modify and expand his spreadsheet based on our feedback. Two more worksheets were added. The states, which were named alphabetically, were rapidly approaching the letter Z...
The client was a bit unhappy, because I had no choice but to submit a change request for tens of thousands of euros to cover the additional costs. How could they suddenly have to pay so much, even though they didn't want anything different from the initial project? They had even kindly adapted their documentation for us so we could implement it more effectively. For us, however, the workload piled up: Adapting huge state machines, writing and maintaining unit tests for switch-case statements with over 1,000 lines is no fun!
To ensure that the change request wouldn't result in further changes, but rather that we had a truly final version, the customer wanted to review and approve the spreadsheet document internally again. When I returned to the office after three wonderful weeks of vacation, I was surprised to discover that they hadn't revised the spreadsheet at all. Instead, they had created a completely new specification of the desired behavior in a Word document with a few state machine diagrams.
The initial shock was immense! The beautiful spreadsheet document! Our implementation was based 1:1 on these tables – including the names of the states and events. Now there should only be this high-level specification?! Should we now derive the huge tables ourselves from it?!
I started checking whether the high-level specification at least fit the existing tables. A Sisyphean task! Better to try again from the other side and generate the table from the high-level description. And lo and behold: a table that previously had almost 400 cells shrank to a manageable 50 cells! How could that be? Had I overlooked something? Didn't I understand the complexity? Or: Why hadn't I seen it before?
It was due to the magical separation of problem and solution space!
Only now, with the high-level specification written and the customer's desired behavior clearly presented—and, above all, free of suggested solutions—was it possible to find an efficient solution to the problem. The spreadsheet had attempted to describe a solution from the very beginning. But before the high-level specification existed, it wasn't even clear which problem it would address.
Even though we were finally able to find an efficient solution to the problem, the effort and cost of the change request remained considerable. We had to dismantle, discard, and rework a lot. Unfortunately, late insights are always expensive insights!
Therefore, I conclude with the recommendation: First understand the problem, then look for the solution.
Birgit Feld