Discussion Club: Good Programming Practice Brussels 2013

From PhUSE Wiki
Jump to: navigation, search

This is a summary of discussions from the Good Programming Practices discussion club at PhUSE conference 2013, Brussels Monday 14th October, Royal A conference room

  • GPP at PhUSE 2013 Brussels

Good Programming Practice returned to the PhUSE conference in Brussels with an interactive discussion club. We invite to you come along and have your say. The general theme was implementation of GPP.

  • How can we best implement GPP as managers?
  • How can we implement GPP as programmers ?
  • How can we improve the GPP guidance document to aid implementation of GPP?


Implementing the cross-industry PhUSE GPP

Would people be able to use the newly developed GPP guidance?

Questions raised: Would your organization use the GPP industry standard? Use the PhUSE GPP as a minimum standard? What are the advantages/disadvantages of the PhUSE GPP vs own Guidance / Will GPP raise standard?

  • Good as general base/minimum standard but still some disagreements
  • Easier for service providers / onboarding
  • Easier to audit
  • Use of GPP ensures/encourages compliance
  • Reach a higher level of standard

How would you implement GPP? SOP/WI/Job Aide/Other? How do you convince management?

  • No agreement on all contents in the proposed standard
  • Work instruction preferred over SOP
  • Development of standard (SAS) program template to be used as starting point for program development
  • Usage of a GPP template questioned due to existing company internal templates, but checklist to be applied when developing company guidance welcome

GPP Document Naming Conventions Discussion Guide

What areas could benefit from naming conventions? (datasets, programs, outputs, qc programs, others)

  • Question was raised as to whether it is SAS specific and we said yes, the guidance right now is SAS specific
  • Production programs
      • TLGs
      • Macros
        • Global
        • Project specific
  • QC programs
  • Datasets
  • Macro variables and parameters
  • Global
  • Local
  • Temporary datasets
  • Variables
  • Librefs
  • Functions
  • Formats
  • QC formats

What could those naming conventions be?

  • Dataset programs
  • Should have same name as dataset except end in .sas
  • SDTM mapping program
  • Domain
  • Could be used with a prefix to group but that goes against the rule of having dataset programs use the same name as their dataset
  • Could also use a suffix
  • Analysis datasets
  • CDISC
  • FDA reviewer at a Single Day Event supported using AD<endpoint> for key efficacy endpoints
  • This may result in more datasets but can be helpful for the reviewer
  • TLGs
  • Same name as output
  • Descriptive but not too long
  • Use prefix t for table, l for listing, f or g for figures/graphs
  • Convention could be prefix-domain-description-analysis population
  • Some mentioned using table numbers
  • QC programs
  • Use prefix of q, qc, or v
  • After prefix, the name should be the same as production program name
  • Other topics
  • Should case be used or all upper/lower?
  • No spaces
  • Consider dependencies in naming convention so that all datasets used are incorporated into the name?
  • Use of version numbers
  • for ad-hoc changes/additions to a dataset
  • Splitting of datasets for submission
  • Abbreviations must be mindful of double meanings/cultural sensitivity
  • TLG programs and output
    • Talk about use of prefixes for different types of programs.
    • Should programs have the same name as their output?
    • Beyond prefixes, should there be length limits, what about conventions for abbreviating terms, indicating certain types of analyses such as lb for labs?
  • Dataset programs
    • Should dataset programs use CDISC names?
qc-
v_
suffix instead of prefix so they sort
one qc program for multiple outputs
multiple qc programs for multiple outputs produced by a single primary program
  • QC program naming conventions.

Do you have standard naming conventions in your organisation?

actual standard or just common practice
  • Most said yes, but they are more general than what we discussed

GPP Document Section Review Discussion Guide

  • Coding conventions
    • Which are the most important?
    • Talk about examples of where they have had impact.
    • Are they all clear/rewording?
    • Anything missing?
    • Rules on indentation in code
  • Other sections


Costs and benefits of Adherence / non Adherence to GPP standards

Efficiency

Efficiency can mean

  • Running efficient code
  • Transfer-ability of code between users

Cases where lack of GPP caused delays

  • Rework needed due to lack of understanding

Quality

  • Lack of Defensive Programming
    • Means-- Program's not working when data changes
    • Code not robust enough to cope with data changes
  • Program to a good spec, NOT the data
  • Lack of version Control / history -> Leads to investigation which costs time
  • lack of good commenting -> leading to delay

Implementing GPP

  • Programmers require Knowledge/preparation
    • Need to develop Good habits
    • There is a training cost to all of this that needs evaluating

Enforcement of GPP

All in the discussion agreed that there were benefits to GPP and that most programming managers agreed with this statement, so what else would be needed to put GPP into practice? The following were suggested as ways of enforcing

  • Peer Review
  • SOPs
  • Programming team buy-in
    • Top down Manager, Project lead, Team lead must buyin/show by example
  • Automated checks save time
    • and should be built into culture and process

Metrics

How can you measure whether you are implementing GPP

  • Unit testing
    • Consider unit testing techniques for developing code
      • Counting errors-> Identifying the most common ones

Benefits of implementing GPP

Had anyone seen obvious benefits from implementing GPP?

  • Repeated Deliveries - drives up efficiency on subsequent deliveries