From subroutines to subsystems: component-based software development

In the early days of programming, when machines were hard-wired and every byte of storage was precious, subroutines were invented to conserve memory. Their function was to allow programmers to execute code segments more than once, and under different (parameterized) circumstances, without having to duplicate that code in each physical location where it was needed. Software reuse was born. However, this was a different breed of reuse than we know today: This was reuse to serve the machine, to conserve mechanical resources. Reuse to save human resources was yet to come. Soon, programmers observed that they could insert subroutines extracted from their previous programs, or even written by other programmers, and take advantage of the functionality without having to concern themselves with the details of coding. Generally-useful subroutines were collected into libraries, and soon very few people would ever again have to worry about how to implement, for example, a numerically-well-behaved double-precision cosine routine. This phenomenon represented a powerful and fundamental paradigm shift in how we regarded software. Invoking a subroutine from a library became indistinguishable from writing any other statement that was built in to the programming language being used. Conceptually, this was a great unburdening. We viewed the subroutine as an atomic statement -- a component -- and could be blissfully unconcerned with its implementation, its development history, its storage management, and so forth.