View source for Programming in the large and programming in the small

{{short description|Adage in software engineering}}
{{multiple issues|{{technical|date=May 2018}}
{{Refimprove|date=February 2010}}}}

In [[software engineering]], "'''programming in the large'''" and "'''programming in the small'''" refer to two different aspects of [[software development|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",<ref>{{Cite book|chapter-url=https://doi.org/10.1145/800027.808431|chapter=Programming-in-the large versus programming-in-the-small|first1=Frank|last1=DeRemer|first2=Hans|last2=Kron|title=Proceedings of the international conference on Reliable software -|date=April 1, 1975|volume=10|issue=6|publisher=Association for Computing Machinery|pages=114–121|via=ACM Digital Library|doi=10.1145/800027.808431|s2cid=1022671}}</ref> 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.

This may be compared to the later [[Ousterhout's dichotomy]], which distinguishes between [[system programming]] languages (for components) and [[scripting language]]s (for [[glue code]], connecting components).

==Description==
[[Fred Brooks]] identifies that the way an individual program is created is different from how a programming systems product is created.<ref name="Brooks" /> 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 (computer science)|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 [[computer programming|programming]] by larger groups of people or by smaller groups over longer time periods.<ref name="Brooks">Brooks, Frederick P., Jr. (1982).  "The Tar Pit", published in ''The Mythical Man-Month – Anniversary Edition''. {{ISBN|0-201-83595-9}}</ref> 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 [[Modularity (programming)|modules]] with precisely specified interactions. This requires careful planning and documentation.

With programming in the large, program changes can become difficult.<ref name="Brooks" /> 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 (computer science)|cohesion]] and loose [[Coupling (computer science)|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 system|state transition]] logic of a [[system]].{{Dubious|date=December 2008}} This logic encodes information such as when to wait for [[message (computer science)|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 [[Type system|loosely typed]] [[scripting language]] in preference to a [[Type system|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|date=December 2008}}

== References ==
{{Reflist}}

== Further reading ==
* {{cite conference
  | first = Frank
  | last = DeRemer
  |author2=Kron, Hans
  | title = Programming-in-the large versus programming-in-the-small
  | book-title = Proceedings of the international conference on Reliable software
  | pages = 114–121
  | publisher = [[Association for Computing Machinery]]
  | year = 1975
  | location = [[Los Angeles, California]]
  | doi = 10.1145/800027.808431
  | doi-access = free
  }}

{{Programming paradigms navbox}}

[[Category:Programming paradigms]]
[[Category:Software engineering folklore]]