Representation is the Essence of Programming

Representation is how you decide to translate “I’d like an app to track the things I have to do everyday” into a data model. The data model is how you translate the requirements of the program into something you can code with. For example with a todo the data model could look something like

interface todo {
 title: string;
 description: string;
 status: boolean
}

Features are made possible, impractical, or impossible by the data model. The features enabled by the above data model include, searching by title, alphabetizing by title, searching by word in description or title, filtering by done or not done. It doesn’t include the idea of priority or responsibility. So users would not be able to indicate that a todo is more important than the others or assign the responsibility for completing a todo. It makes adding a ‘Pending’ status impossible.

If we wanted to support more features we should change how we represent todos.

Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of a program lies. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

interface todo {
 title: string;
 description: string;
 status: 'To do' | 'Pending' | 'Done';
 priority: 'High' | 'Medium' | 'Low';
 assignee: User;
}

I think this is a basic idea that is not taken seriously enough. The only thing that code has to work with is the data model. A new feature means a change to the data model. If the data model is hard to change, your code is hard to change.