Problem Domains

I came across a book about making your own operating system. While it’s extremely heavy in regard to assembly code manipulation there is an early section that suck out to me that I’d like to preserve here. Please checkout the full book here: https://github.com/tuhdo/os01 It was the first piece of literature that helped me to frame how exactly a problem interfaces between different systems and that need translation for the desired effect to occur.

Problem domains

In the real world, software engineering is not only focused on software, but also the problem domain it is trying to solve.

A problem domain is the part of the world where the computer is to pro-duce effects, together with the means available to produce them, directly or indirectly. (Kovitz, 1999)

A problem domain is anything outside of programming that a software engineer needs to understand to produce correct code that can achieve the desired effects. “Directly” means include anything that the software can control to produce the desired effects, e.g. keyboards, printers, monitors, other software, etc. “Indirectly” means anything not part of the soft-ware but relevant to the problem domain e.g. appropriate people to be informed by the software when some event happens, students that move to correct classrooms according to the schedule generated by the soft-ware. To write a finance application, a software engineer needs to learn sufficient finance concepts to understand the requirements of a customer and implement such requirements, correctly.

Requirements are the effects that the machine is to exert in the problem domain by virtue of its programming.

Programming alone is not too complicated; programming to solve a problem domain, is 1. Not only a software engineer needs to understand how to implement the software, but also the problem domain that it tries to solve, which might require in-depth expert knowledge. The software engineer must also select the right programming techniques that apply to the problem domain he is trying to solve because many techniques that are effective in one domain might not be in another. For example, many types of applications do not require performant written code, but a short time to market. In this case, interpreted languages are widely popular because it can satisfy such need. However, for writing huge 3D games or operating system, compiled languages are dominant because it can generate the most efficient code required for such applications.

Often, it is too much for a software engineer to learn non-trivial do-mains (that might require a bachelor degree or above to understand the domains). Also, it is easier for a domain expert to learn enough programming to break down the problem domain into parts small enough for the software engineers to implement. Sometimes, domain experts implement the software themselves.

Figure 1.1.1: Problem domains: Software and Non-software.

One example of such scenario is the domain that is presented in this book: operating system. A certain amount of electrical engineering (EE) knowledge is required to implement an operating system. If a computer science (CS) curriculum does not include minimum EE courses, students in the curriculum have little chance to implement a working operating system. Even if they can implement one, either they need to invest a significant amount of time to study on their own, or they fill code in a pre-defined framework just to understand high-level algorithms. For that rea-son, EE students have an easier time to implement an OS, as they only need to study a few core CS courses. In fact, only “C programming” and “Algorithms and Data Structures” classes are usually enough to get them started writing code for device drivers, and later generalize it into an operating system.

Figure 1.1.2: Operating System domain.

One thing to note is that software is its own problem domain. A problem domain does not necessarily divide between software and itself. Compilers, 3D graphics, games, cryptography, artificial intelligence, etc., are parts of software engineering domains (actually it is more of a computer science domain than a software engineering domain). In general, a software-exclusive domain creates software to be used by other software. Operating System is also a domain, but is overlapped with other domains such as electrical engineering. To effectively implement an operating system, it is required to learn enough of the external domain. How much learning is enough for a software engineer? At the minimum, a software engineer should be knowledgeable enough to understand the documents prepared by hard-ware engineers for using (i.e. programming) their devices.

Learning a programming language, even C or Assembly, does not mean a software engineer can automatically be good at hardware programming or any related low-level programming domains. One can spend 10 years, 20 years or his entire life writing C/C++ code, and he still cannot write an operating system, simply because of the ignorance of relevant domain knowledge. Just like learning English does not mean a person automat-ically becomes good at reading Math books written in English. Much more than that is needed. Knowing one or two programming languages is not enough. If a programmer writes software for a living, he had bet-ter be specialized in one or two problem domains outside of software if he does not want his job taken by domain experts who learn program-ming in their spare time.

---

¹ We refer to the concept of “program-ming” here as sorneone able to write code in a language, but not necessary know any or all software engineering knowledge.