Judas Priest Ate My ScrumMaster

Community Management in Free Software communities is still an emerging field and has produced a spectrum of practitioners: from master-manipulators of social media, to those more focused on metrics and data as a means to driving process. Either way, the state of the art is still largely driven by the needs of technical contributors to projects.
Good documentation is a crucial component in a software product and yet often technical writers are overlooked as important stakeholders of the process. Within the community, there are undoubtedly common problems between engineers and technical writers. Software Engineering is full of laws; can we show that these laws apply to technical writers as a means to help bridge the chasm between developers and technical writers??
In this talk Paul walks us through a selection of his favourite laws of software engineering and explores how developers measure them and if technical writers must also obey them. Or not. And what that means for the success of documentation in a Free Software project.

Transcript

1. Judas Priest Ate My ScrumMaster Another Questionable Presentation By Dr. Paul J. Adams
2. I Know Nothing. I Come In Peace.
3. 90% Of Everything Is Crap (1. Introduction)
4. Management Matters!
5. Document Writers Unique and beautiful snowflakes. All.
6. I Am The Law! (2. Some Interesting Laws Of Software Engineering)
7. Brooks’ Law (Adding People To A Late Software Project Will Make it Later)
8. Conway’s Law (Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations)
9. Lehmann’s 2nd Law (As software evolves, its c o mp l e x i t y i n c r e a s e s unless work is done to maintain or reduce it)
10. Pareto Law (For any given system, 80% of software bugs will be found in less than 20% of software modules)
11. Tacoma Narrows? (3. Bridging Engineering and Documentation)
12. Wait… What?
13. Lehman’s 5th Law (As a system evolves, all associated with it, developers, sales personnel and users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery)
14. We’re All In This Together!
15. Free Software Open Source Products (#boom #micdrop)