Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Judas Priest Ate My ScrumMaster

285e2691517b3ecd122e587c65e9d9ad?s=47 Paul Adams
September 01, 2015

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.


Paul Adams

September 01, 2015

More Decks by Paul Adams

Other Decks in Programming


  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

  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)