Programming in the large and programming in the small

Last updated January 22, 2025

In software engineering, "programming in the large" and "programming in the small" refer to two different aspects of writing software. "Programming in the large" means designing a larger system as a composition of smaller parts, and "programming in the small" means creating those smaller parts by writing lines of code in a programming language. The terms were coined by Frank DeRemer and Hans Kron in their 1975 paper "Programming-in-the-large versus programming-in-the-small",^[1] in which they argue that the two are essentially different activities, and that typical programming languages, and the practice of structured programming, provide good support for the latter, but not for the former.

Description

Fred Brooks identifies that the way an individual program is created is different from how a programming systems product is created.^[2] The former likely does one relatively simple task well. It is probably coded by a single engineer, is complete in itself, and is ready to run on the system on which it was developed. The programming activity was probably fairly short-lived as simple tasks are quick and easy to complete. This is the endeavor that DeRemer and Kron describe as programming in the small.

Compare with the activities associated with a programming systems project, again as identified by Brooks. Such a project is typified by medium-sized or large industrial teams working on the project for many months to several years. The project is likely to be split up into several or hundreds of separate modules which individually are of a similar complexity to the individual programs described above. However, each module will define an interface to its surrounding modules.

Brooks describes how programming systems projects are typically run as formal projects that follow industry best practices and will comprise testing, documentation and ongoing maintenance activities as well as activities to ensure that the product is generalized to work in different scenarios including on systems other than the development systems on which it was created.

Programming in the large

In software development, programming in the large can involve programming by larger groups of people or by smaller groups over longer time periods.^[2] Either of these conditions will result in large, and hence complicated, programs that can be challenging for maintainers to understand.

With programming in the large, coding managers place emphasis on partitioning work into modules with precisely-specified interactions. This requires careful planning and documentation.

With programming in the large, program changes can become difficult.^[2] If a change operates across module boundaries, the work of many people may need re-doing. Because of this, one goal of programming in the large involves setting up modules that will not need altering in the event of probable changes. This is achieved by designing modules so they have high cohesion and loose coupling.

Programming in the large requires management skills. The process of building abstractions aims not just to describe something that can work but also to direct the efforts of people who will make it work.

The concept was introduced by Frank DeRemer and Hans Kron in their 1975 paper "Programming-in-the-Large Versus Programming-in-the-Small", IEEE Trans. on Soft. Eng. 2(2).

In computer science terms, programming in the large can refer to programming code that represents the high-level state transition logic of a system.^{[ dubious – discuss ]} This logic encodes information such as when to wait for messages, when to send messages, when to compensate for failed non-ACID transactions, etc.

A language that was designed to explicitly support programming in the large is BPEL.

Programming in the small

In software development, programming in the small describes the activity of writing a small program. Small programs are typified by being small in terms of their source code size, are easy to specify, quick to code and typically perform one task or a few very closely related tasks very well.

Programming in the small can involve programming by individuals or small groups over short time periods and may involve less formal practices (for instance less emphasis on documentation or testing), tools and programming languages (e.g. the selection of a loosely typed scripting language in preference to a strictly typed programming language). Programming in the small can also describe an approach to building prototype software, or when rapid application development is more important than stability or correctness.

In computer science terms, programming in the small deals with short-lived programmatic behavior, often executed as a single ACID transaction and which allows access to local logic and resources such as files, databases, etc.^{[ dubious – discuss ]}

Related Research Articles

Prolog is a logic programming language that has its origins in artificial intelligence, automated theorem proving and computational linguistics.

Procedural programming is a programming paradigm, classified as imperative programming, that involves implementing the behavior of a computer program as procedures that call each other. The resulting program is a series of steps that forms a hierarchy of calls to its constituent procedures.

A programmable logic controller (PLC) or programmable controller is an industrial computer that has been ruggedized and adapted for the control of manufacturing processes, such as assembly lines, machines, robotic devices, or any activity that requires high reliability, ease of programming, and process fault diagnosis.

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

The waterfall model is a breakdown of developmental activities into linear sequential phases, meaning that each phase is passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. This approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment, and maintenance. The waterfall model is the earliest Systems Development Life Cycle (SDLC) approach used in software development.

Zope is a family of free and open-source web application servers written in Python, and their associated online community. Zope stands for "Z Object Publishing Environment", and was the first system using the now common object publishing methodology for the Web. Zope has been called a Python killer app, an application that helped put Python in the spotlight.

A programming paradigm is a relatively high-level way to conceptualize and structure the implementation of a computer program. A programming language can be classified as supporting one or more paradigms.

Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.

Software development is the process of designing and implementing a software solution to satisfy a user. The process is more encompassing than programming, writing code, in that it includes conceiving the goal, evaluating feasibility, analyzing requirements, design, testing and release. The process is part of software engineering which also includes organizational management, project management, configuration management and other aspects.

Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety. It is claimed that the process described below is only slightly slower and more costly than the normal ad hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive and reliable way to produce software. In some projects however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix.

In the history of artificial intelligence (AI), neat and scruffy are two contrasting approaches to AI research. The distinction was made in the 1970s, and was a subject of discussion until the mid-1980s.

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect or "concern" of the desired functionality.

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

Coding best practices or programming best practices are a set of informal, sometimes personal, rules that many software developers, in computer programming follow to improve software quality. Many computer programs require being robust and reliable for long periods of time, so any rules need to facilitate both initial development and subsequent maintenance of source code by people other than the original authors.

Automata-based programming is a programming technology. Its defining characteristic is the use of finite-state machines to describe program behavior. The transition graphs of state machines are used in all stages of software development. Automata-based programming technology was introduced by Anatoly Shalyto in 1991. Switch-technology was developed to support automata-based programming. Automata-based programming is considered to be rather general purpose program development methodology than just another one finite-state machine implementation.

In computer science and computer engineering, computer architecture is a description of the structure of a computer system made from component parts. It can sometimes be a high-level description that ignores details of the implementation. At a more detailed level, the description may include the instruction set architecture design, microarchitecture design, logic design, and implementation.

Software construction is a software engineering discipline. It is the detailed creation of working meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. It is linked to all the other software engineering disciplines, most strongly to software design and software testing.

Software architecture description is the set of practices for expressing, communicating and analysing software architectures, and the result of applying such practices through a work product expressing a software architecture.

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

This glossary of computer science is a list of definitions of terms and concepts used in computer science, its sub-disciplines, and related fields, including terms relevant to software, data science, and computer programming.

References

↑ DeRemer, Frank; Kron, Hans (April 1, 1975). "Programming-in-the large versus programming-in-the-small". Proceedings of the international conference on Reliable software -. Vol. 10. Association for Computing Machinery. pp. 114–121. doi:10.1145/800027.808431. S2CID 1022671 – via ACM Digital Library.
1 2 3 Brooks, Frederick P., Jr. (1982). "The Tar Pit", published in The Mythical Man-Month – Anniversary Edition. ISBN 0-201-83595-9