This post does not contain unique ideas, this is just my understanding of a good video I recently found on youtube. You can scroll down to find a link to the original video talk on this topic.

In 1970s Manny Lehman suggested a set of Lehman's laws of software evolution. These laws only apply to a certain type of systems so he divided the systems into three categories:
- E-type
- P-type, and
- S-type systems

So let's start with S-type systems. So S-type systems are systems that have well-known specifications that have a well-known solution. So if somebody for example asks you to implement bubble sort or implement a particular mathematical function that has an own specification and a known solution, it is possible to exactly say whether the program is correct or not. And that's why it is possible to implement a 100% correct solution.

Moving on P-type systems. P-type systems might actually have a specification in terms of what a 100% correct solution would be. There might even be a way of theoretically reaching that perfect solution, but in practice it would be utterly infeasible to actually implement that solution. So a good example of such a system would for example be chess if you want to develop an algorithm that plays chess perfectly. It is theoretically possible to construct the perfect solution, but in practice if you would run that solution the combinatorial complexity is way too high. So it is intractable. The solution is intractable so you can't actually use that solution because your program will never be able to make a move because it's all always thinking too long. So as you can imagine this brings in even more programs.

But let's now talk about E-type systems. So E-type systems are real world systems. Systems that are intertwined with processes of real life, with business processes, with real people where there is not necessarily a specification of 100% correctness. Because the specification is ever-changing we're not really entirely sure what we want to have. Or even if we are sure what we want to have, we're not necessarily sure that what we want to have today is what we're gonna have tomorrow. It's important to emphasize that that's not necessarily just because of uncertainty. That's because it's operating an environment that's subject is to change people's needs. The business need might actually for very good reasons change over time, which means that the specification of our system is not stable. So to contrast this with P-type systems think about chess again. If you're seeking an algorithm that plays chess perfectly then that might be a P-type system. But if you're developing a game in which there also is an algorithm that plays chess then that whole system is probably an E-type system, because suddenly you have loads of other things to take into account as well, such as for example: the use interface, what key combinations you use to interact with the program, how to boot the program, etc. These are things that are non-stable in any real world environment.

It's useful to know about these different types of systems, because in most of the environments where we are developing systems as programmers we are actually dealing with E-type systems and not P-type and not S-type systems.

So when people are arguing against things such as for example abstraction we need to carefully listen to their arguments. We need to consider whether they are arguing as if we were building a P-type or S-type system, because if they are then we are fundamentally disagreeing on a different level. We first need to agree that we are talking about E-type systems and then realize that the notion of E-type systems is that they are to change, and we cannot be 100% certain about the specification. We cannot be 100% certain that the specification of today will be the specification of tomorrow, which I would humbly argue should lead us into thinking about our design in a different way than if we were building a P-type or S-type systems.

So to sum up in S-type systems we can specify the program with 100% correctness and we can talk about the perfect solution of the problem. The the problem is well understood and the solution is well understood. But in P-type systems the problem can be well understood and the solution can be well understood, but it's practically impossible to actually implement the perfect solution. And E-type systems are the systems that we usually deal with on a day-to-day basis. Systems that are subject to change. Systems that solve problems that are deeply interlinked with social processes or social environments.

View an original video talk on this topic