veyepar: Programming Considered Harmful

Author(s):	Dave Chinner
Location	OGGB3
Date	jan Thu 15	Days Raw Files
Start	16:35	First Raw Start	15:45
Duration	0:45:00	Offset	0:49:33
End	17:20	Last Raw End	17:23
Chapters	00:00
Total cuts_time	42 min.

http://lca2015.linux.org.au/schedule/30034/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf Programming_Considered_Harmful.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

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.

Comment:

production notes