Peter Miller (software engineer)

{{Short description|Australian software developer}}

{{Use dmy dates|date=April 2018}}

{{Use Australian English|date=April 2018}}

{{Infobox person

| name = Peter Miller

| image = Peter Miller.jpg

| caption = Miller in October 2011

| birth_name = Peter Alexander Miller

| birth_date = {{birth date|df=yes|1960|10|16}}

| birth_place = Ramsgate, New South Wales

| death_date = {{death date and age|df=yes|2014|7|27|1960|10|16}}

| death_place = Green Point, New South Wales

| occupation = Software Engineer

| website =

| years_active =

| nationality = Australian

| spouse = Mary Therese Miller (nee Lynch) (married 198?-2014)

| children = Rowan Miller (1989-present)

| parents = {{unbulleted list|Ronald William Miller|Jane Penelope Miller (nee Phelam)}}

}}

Peter Miller (16 October 1960 – 27 July 2014) was an Australian software developer who wrote [http://www.real-linux.org.uk/recursivemake.pdf Recursive Make Considered Harmful]{{cite news | url=http://www.linux-mag.com/id/2101/ | archive-url=https://web.archive.org/web/20070715095642/http://www.linux-mag.com/id/2101/ | url-status=usurped | archive-date=15 July 2007 | title=Recursive make Reloaded | first=John | last=Graham-Cumming | work=Linux Magazine | date=15 July 2005 | accessdate=13 April 2018 }}{{Cite web|url=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|title = Google Scholar}} and created [https://web.archive.org/web/20141014045738/http://aegis.sourceforge.net/ Aegis] and [https://web.archive.org/web/20140622050724/http://miller.emu.id.au/pmiller/software/cook/ cook]. He also proposed a set of "laws" for modern software engineering and architecture in the early 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.