Dave Chinner
http://lca2015.linux.org.au/schedule/...
I recently came across a statement on LKML:
' › Reviewed by: ‹someone@somewhere.com› I'm not looking for reviews - I'm looking for testers.
'
As an engineer, this struck me as fundamentally wrong. The ensuring discussion over whether the definition of "free of known issues" meant that the reviewer needed to apply and test the patch was not very rewarding.
In the discussion, the academic peer review model was cited as the reason that reviewers don't need to test the code they review - reading the change is enough to find all known problems. My response was that software engineering code review requires the reveiwer to perform due diligence and that implies a reviewer must apply, test and verifying the code under review. These are very different views on what is supposedly a well defined process.
A further commenter quoted Dijkstra, mocking my views on software engineering process: 'If you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."'
During this talk, I will demonstrate that humans cannot Program. There is evidence *everywhere* that we fail badly at Programming and we repeatedly demonstrate that our attempts to Program don't improve as complexity increases. Using examples from the Linux Kernel, I'll state my case for why I think we should be engineering complex software rather than Programming, and how that impacts on our code design and review processes.
