The Tar Pit

In his post "Propositions as Filenames, Builds as Proofs: The Essence of Make", Bob Atkey describes the make build utility as a tool for the construction of proofs based on a set of rules, in a similar (or at least not dissimilar) way to Prolog. This makes Makefile a logic programming (meta)language used to describe build pre and post-conditions, plus (optionally) the contract implementation, i.e. how the rule can be applied once the pre-conditions are met.

Aside from describing the fundamental model, the post also makes a short yet interesting comparison with other build tools:

Many alternatives to make have been proposed. Motivations for replacing make range from a desire to replace make's very Unix-philosophy inspired domain-specific language for describing build rules (Unix-philosophy in the sense that it often works by coincidence, but falls over if you do something exotic, like have filenames with spaces in, or have an environment variable with the “wrong” name), or make's slowness at some tasks, or a perception that make doesn't treat the make-alternative implementor's favourite programming language with the special treatment it so obviously deserves.

These points, and specifically the point regarding the Unix philosophy, are uncoincidentally the same as those brought in the "SysVinit versus systemd" debate: while init scripts have various issues, performance being but one of them, the hard separation between policy and the actual init implementation is what makes system administrators prefer the legacy solution rather than the new, full-featured stuff. On the other hand, the fact that systemd boots faster brings a null advantage to system administrators, since they want to maintain machines that are rebooted very rarely (if ever).

These examples are but a few illustrations of the crisis of the field of software engineering, more specifically the "engineering" part. As much as I don't like quoting Wikipedia, it provides a few very good definitions of the term's meaning:

Typical formal definitions of software engineering are:

• "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software";¹
• "an engineering discipline that is concerned with all aspects of software production";²
• and "the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines."³

The first and last definitions are particularly good, stating that software development needs to be systematic and that it needs to rely on theory, method and principle. That is, the outcome of the development process must rely solely on the requirements and the end result should be quantifiable in the scientific sense of the word. Also, the duration of the development process needs to be estimated with a good degree of accuracy⁴, not only for the sake of providing the engineers with determinism in terms of costs and not only for the sake of providing a "time-to-market", but also to be in line with the "theory, method and principle" guideline.

This is very far from the current state of the software industry and software⁵ engineering. Software engineering methods and principles do exist, only they are either faulty by design⁶ or they involve throwing an army of developers at some particular problem⁷. This process "scales" in the sense that the end product will be "good enough"⁸, but the costs involved are so big that they would be better spent trying to improve software quality by design. That is not to say that software engineering should not involve any hacking at all; on the contrary, only that hacking should not come at the expense of science.

To add insult to injury, the complexity of most real-life software systems requires the software engineering process to scale up, and this has nothing to do with code. Writing code is cheap, sound design is however mind-bogglingly hard, and at the same time essential⁹. At the same time software complexity conflicts with two aspects of software engineering.

The first aspect is that of establishing requirements. While simple systems, say, real-time DPSs, have well-defined requirements, some of the complex systems are subject to requirements that are often ambiguous. "Engaging users" isn't a non-ambiguous requirement¹⁰ and thus making software to meet it is a joke. Even some of the seemingly clear requirements are in fact hard to establish: for example building a platform to facilitate communication between people is a hard problem: doesn't IRC satisfy this requirement? don't blogs satisfy it? why are people looking into "integrated" products?

Secondly, software specification is the bottleneck. Again, it is fairly easy to specify simple systems, even when they are built as isolated components of larger systems, such as, say, software control components for automobiles. It's however very difficult to specify a social network, given that the term itself is ambiguous. Is IRC a social network?

This isn't to say that there aren't large systems that can be formally specified: Bitcoin is one such example. Facebook, on the other hand is a counter-example. This is incidentally why Bitcoin is infrastructure, while Facebook cannot, and never will attain that status. This proves the point that the concept of social network, even if we don't view it as a marketing object, doesn't make sense in the context of software engineering.

This in turn shows that software engineering has become somewhat of a myth. It's not only that it's hard to make reliable software, it's also hard to make software that's unambiguously useful¹¹. Stallman's Emacs is reliable and useful because it does one thing well¹². djb's qmail is reliable and useful because it does one thing well. systemd on the other hand is not reliable and useful, because it has "neat features". Google Play is not reliable and useful, because "it's social".

Of course, this doesn't really matter to the user, it just makes developers' lives a hell.

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.