Commentary Software engineering is the act of coordinating software workers (designers, developers, testers, etc.) for the purpose of producing and maintaining software. The central problem of software engineering is thus: The best way to develop the implementation of a software module is by frequent incremental changes. The worst way to develop the interfaces between software modules is by frequent incremental changes. These two things are often referred to as "programming in the small" and "programming in the large", although size really has nothing to do with it — it's all about the number of cross-references. There are, of course, other problems of software engineering, but they all tend to relate to the central problem. That said, here is Cat's Eye Technologies official position on software engineering: Don't. Obviously we don't mean that. Or do we? There are two schools of thought about how to maintain systems that are "larger" (read: have more cross-references) than a single person, or a single team, can fully comprehend. Most modern software falls into this category. One is to throw resources at it, on the model of evolutionary growth, or trial and error: look for things that look promising to change (perhaps because it looks like others changed them when trying to do something similar,) change them, and once it does more or less what you want, hope nothing else has been broken and for God's sake don't touch it again!! The other is to try to understand the system, possibly by reducing it into smaller systems that are easier to understand while codifying and documenting the interfaces between the systems. If the first is the approach embodied by mainstream software engineering — and I'd like to believe it isn't but from what I've seen it is — then no. We don't want any part of that. Nondeterministic behaviour from a Makefile? We want to know why. It's not enough to throw in targets and dependencies (and perhaps even pauses) so that it doesn't usually happen. Yes, you can get back to work on your "real" project that way, but you're digging a huge hole for yourself in the long view — you're not solving the underlying problem and you're increasing the complexity of the system. You might say we belong to the Edsger Dijkstra school of software engineering.