The form of a table

For a little while I've been obsessed with Plato's World of Forms. Not just as a concepts, also in my professional work as a software engineer. An abstract concept like perfect forms in a separate universe might seem far fetched to apply to software engineering, I do think it can be useful to understand.

The world of Forms

In short, Plato's theory of Forms is the belief that everything in our world is nothing but an imperfect copy of the perfect form that exists in the 'world of forms'. So anything, like a table, is just an approximation of the perfect table. And with our human sense we are not able to percieve the perfect world of forms, only the 'earthly' representations. This all sounds extremly abstract, so let's make it more concrete.

The perfect form of a table

Tables come in all shapes and sizes, but whatever they look like we all recognize them as tables. There is no law that says a table should have four legs or the top should be rectangular shaped. The height as well, there are some standard heights but these differ by region and use case. You won't have a dinner table as a coffee table or a bar table as a desk.

The essence of a table

The perfect form of a table isn't a strict definition, but it's the concept of a table and what it represents. What Aristotle would call an object's "essence".

The perfect form of anything probably isn't 'perfect' by assigning more and more restrictions, but by stripping away as many definitions until you arrive at the minimum of what this form is. What is left when everything else is stripped away. In that sense the perfect form of a table is nothing more than "a raised flat surface".

How is this important for software engineering?

The theory of Forms can most easily be used to describe the problem often encountered when writing user stories. It's very hard not to make assumptions when describing a feature. But a lot of requests are dependend on the (full) context, not only of the request but also of who requests it.

Let's imagine, instead of software we make furniture, and we get a request which simply states "We want a table". What should we deliver? If there are no further requirements both a coffee table or a picknick table would fit. We're missing the context of the Table. Why do we need a table? Is a table indeed what we need? And that's by already assuming they want a physical table, and not one in a database.

Contextualize the request

So let's add a bit of context to our user story "As a restaurant we want a table". At least now we can assume the table is to be used for eating. A picknick table might technically still fit, but a dinner table might be more logical. If they give us more context, for example "As a Italian restaurant we want a table so we can host large dinner parties" we know a lot more. We can get from here that is should be a large dinner table that fits the aesthetic of an Italian restaurant.

This still leaves a lot of room for assumptions, but we can probably judge a resulting table by this. An other way to add even more context (or constraints) is to specify acceptance criteria. Adding things like "The table should be able to fit 30 people" or "The table should be made of a dark wood" all help specifying the table the client wants.

If we're asked to deliver a table, any raised flat surface is correct until there are more requirements that define this table.

Conclussion

Words without context are just words, the word 'table' has different meanings based on the context surrounding it. By adding context to a word, we can assume with more and more certainty. Our job as software engineers is to translate these words into useful software, and the more context we have, the more useful this software can be. The requirements and constraints turn a 'raised surface' into the table a client needs.

Powered by wisp