2020-07-21 Collegeville Day 1 Breakout Discussion

Participants

good to have some people focused on each aspect
short-term results, while important, you need to keep an eye out for the long term.

productivity: how much effort does it take to achieve your goal?
- goals are always evolving, each person has different goals
- problem comes when goals are in conflict

hard to normalize wrt to different goals
how do individuals measure productivity?
- is self assessment (without quantification) enough?
frustration / emotional state is a big indicator about productivity

teams need to learn from the macro failure of ‘wasted’ effort
as long as an individual learns during the process, maybe
Is the “wasted” work the only way you could have reached the conclusion that this was the wrong approach?
- how can we reduce the “wasted” effort next time around?
is there a de-brief that not only looks at what lead to the failure, but then communicates this to others

you know it when you see it
inefficient -> duplication of effort
matching individual skills to the right problems
- resources aligned to the problem

example: how to get the team to write documentation?
- one person would start writing the documentation, then hand it off to a second person to take it over and own it.
- useful to build documentation with other people
- paired programming / paired documentation
interpersonal challenge, both people need to get credit for the end result, both the documenter and the ‘original coder’
what are the incentive structures at the management level? can you change those to the get the behavior that you want?
project manager & system engineer roles with opposite incentives.
- project manager: deliver on time
- system engineer: deliver a quality product
- in DOE, these roles might be handled by the same person. maybe it should be more explicit, so that people can think clearly about what needs to be done.

wait for the community to reach critical mass on a tool before personally investing in it
good news for tool developers, keep running sessions and getting the word out

it may depend on the type of tool that management
forced to use a macbook
management can make tools available: atlassian suite, make it easier to use
- need ‘fresh blood’ people who know whats out there, and can bring it in to the internal work

CI testing
- getting teams used to using that
- making it easier to learn / documentation
- how long can you use the resources?
- which tests exercise the code that was changed?
- and this needs to be automated, not chosen by a human
spack for system administrators
CI with spack does has some technical challenges
tools that are otherwise available, working on HPC systems
- identify where the gap is small, but the benefit would be large

recognize the problems
have good community education in place
can we do requirements gathering, before jumping in to technical solutions, esp. if we are solving a problem as a community and each side has their tool to evangelize
requirements gathering is a super import part of the process
common file format? each lab had a different experience, but then had vastly different requirements
- have an objective 3rd party to bring everyone to the table and find the common ground
- 3rd party owning the result, not any one lab
- community branding, not just any individual lab
- allow people doing the work the ability to collaborate, without the branding discussion