Editing Form follows function (section)

=== Software engineering ===
It has been argued that the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any. This does not mean that process is irrelevant, but that processes compatible with an artifact's requirements lead to roughly similar results.<ref>{{cite conference
  | first = Diomidis
  | last = Spinellis
  | author-link = Diomidis Spinellis
  | title = A Tale of Four Kernels
  | book-title = ICSE '08: Proceedings of the 30th International Conference on Software Engineering
  | pages = 381–390
  | publisher = Association for Computing Machinery
  | date = May 2008
  | location = Leipzig, Germany
  | url = http://www.dmst.aueb.gr/dds/pubs/conf/2008-ICSE-4kernel/html/Spi08b.html
  | doi = 10.1145/1368088.1368140
  | access-date = 2011-10-19
| url-access = subscription
  }}</ref>

The principle can also be applied to enterprise application architectures of modern business, where "function" encompasses the business processes which should be assisted by the enterprise architecture, or "form". If the architecture were to dictate how the business operates, then the business is likely to suffer from inflexibility and the inability to adapt to change.{{Citation needed|reason=Then quid of the book "Team Topologies"? - https://teamtopologies.com/|date=December 2022}} [[Service-oriented architecture]] enables an [[enterprise architect]] to rearrange the "form" of the architecture to meet the functional requirements of a business by adopting standards-based communication protocols which enable interoperability. This stands in conflict with [[Conway's law]],{{Citation needed|reason=Then quid of the book "Team Topologies"? - https://teamtopologies.com/|date=December 2022}} which states from a social point of view that "form follows organization".

Furthermore, [[domain-driven design]] postulates that structure ([[software architecture]], [[design pattern]], [[implementation]]) should emerge from constraints of the modeled domain ([[functional requirement]]).

While "form" and "function" may be more or less explicit and invariant concepts to the many engineering doctrines, [[metaprogramming]] and the [[functional programming]] paradigm lend themselves very well to explore, blur and invert the essence of those two concepts.

The [[agile software development]] movement espouses techniques such as "[[test-driven development]]", in which the engineer begins with a minimum unit of user-oriented functionality, creates an automated test for such and then implements the functionality and iterates, repeating this process. The result and argument for this discipline are that the structure or "form" emerges from actual function, and in fact because done organically, makes the project more adaptable long-term, as well of as higher-quality because of the functional base of automated tests.{{cn|date=December 2024}}