As a next-generation build tool, &SCons; should fundamentally improve on its predecessors. Rather than simply being driven by trying to not be like previous tools, &SCons; aims to satisfy the following goals: Practicality The &SCons; design emphasizes an implementable feature set that lets users get practical, useful work done. &SCons; is helped in this regard by its roots in &Cons;, which has had its feature set honed by several years of input from a dedicated band of users. Portability &SCons; is intended as a portable build tool, able to handle software construction tasks on a variety of operating systems. It should be possible (although not mandatory) to use &SCons; so that the same configuration file builds the same software correctly on, for example, both Linux and Windows NT. Consequently, &SCons; should hide from users operating-system-dependent details such as filename extensions (for example, .o vs. .obj). Usability Novice users should be able to grasp quickly the rudiments of using &SCons; to build their software. This extends to installing &SCons;, too. Installation should be painless, and the installed &SCons; should work "out of the box" to build most software. This goal should be kept in mind during implementation, when there is always a tendency to try to optimize too early. Speed is nice, but not as important as clarity and ease of use. Utility &SCons; should also provide a rich enough set of features to accommodate building more complicated software projects. However, the features required for building complicated software projects should not get in the way of novice users. (See the previous goal.) In other words, complexity should be available when it's needed but not required to get work done. Practically, this implies that &SCons; shouldn't be dumbed down to the point it excludes complicated software builds. Sharability As a key element in balancing the conflicting needs of Usability and Utility, &SCons; should provide mechanisms to allow &SCons; users to share build rules, dependency scanners, and other objects and recipes for constructing software. A good sharing mechanism should support the model wherein most developers on a project use rules and templates that are created and maintained by a local integrator or build-master, Extensibility &SCons; should provide mechanisms for easily extending its capabilities, including building new types of files, adding new types of dependency scanning, being able to accomodate dependencies between objects other than files, etc. Flexibility In addition to providing a useful command-line interface, &SCons; should provide the right architectural framework for embedding its dependency management in other interfaces. &SCons; would help strengthen other GUIs or IDEs and the additional requirements of the other interfaces would help broaden and solidify the core &SCons; dependency management.