Peter Miller (software engineer): Difference between revisions
migrating Persondata to Wikidata, please help, see challenges for this article |
Rescuing 1 sources and tagging 0 as dead. #IABot (v1.6.1) (Balon Greyjoy) |
||
Line 18: | Line 18: | ||
}} |
}} |
||
'''Peter Miller''' (October 16, 1960 – July 27, 2014) was an Australian software developer who wrote [http://aegis.sourceforge.net/auug97.pdf Recursive Make Considered Harmful]<ref>http://www.linux-mag.com/id/2101/</ref><ref>https://scholar.google.com.au/scholar?es_sm=119&bav=on.2,or.r_cp.&bvm=bv.93564037,d.dGc&biw=1280&bih=678&um=1&ie=UTF-8&lr&cites=14823016308468608480</ref> and created [[Aegis (management software)|Aegis]] and [http://miller.emu.id.au/pmiller/software/cook/ cook]. He also discovered the laws of modern software engineering and architecture in the early 1990s (before others rediscovered them in the late 1990s): |
'''Peter Miller''' (October 16, 1960 – July 27, 2014) was an Australian software developer who wrote [http://aegis.sourceforge.net/auug97.pdf Recursive Make Considered Harmful]<ref>http://www.linux-mag.com/id/2101/</ref><ref>https://scholar.google.com.au/scholar?es_sm=119&bav=on.2,or.r_cp.&bvm=bv.93564037,d.dGc&biw=1280&bih=678&um=1&ie=UTF-8&lr&cites=14823016308468608480</ref> and created [[Aegis (management software)|Aegis]] and [https://web.archive.org/web/20140622050724/http://miller.emu.id.au/pmiller/software/cook/ cook]. He also discovered the laws of modern software engineering and architecture in the early 1990s (before others rediscovered them in the late 1990s): |
||
Miller's laws are: |
Miller's laws are: |
Revision as of 09:41, 27 November 2017
Peter Miller (October 16, 1960 – July 27, 2014) was an Australian software developer who wrote Recursive Make Considered Harmful[1][2] and created Aegis and cook. He also discovered the laws of modern software engineering and architecture in the early 1990s (before others rediscovered them in the late 1990s):
Miller's laws are:
1. The number of interactions within a development team is O(n!) without controlled access to the baseline. If the development team does have controlled access to the baseline, interactions can be reduced to near O(n), where n is the number of developers and/or files in the source tree, whichever is larger.
2. The baseline MUST always be in working order.
3. The software build/construction process can be reduced to a directed, acyclical graph (DAG).
4. It is necessary to build a rigid framework of selected components (aka the top level aegis design).
5. The framework should not do any real work, and should instead delegate everything to external components. The external components should be as interchangeable as possible.
6. The framework should use the Strategy pattern for most complex tasks.
References
External links
- Debian Project mourns the loss of Peter Miller October 20, 2014