Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Short Article: The Myth of Developer Productivity #1484

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bartlettroscoe
Copy link
Member

Description

EB Member: @markcmiller86 ?

Resolves #1341

NOTE: This is a WIP draft PR to develop this content collaboratively. Once we are ready for a final review and testing, we will remove the "WIP:" prefix and "draft" status.

PR checklist for files displayed on bssw.io site

  • [Author] @mention the BSSw.io editorial board member @<eb-member-id> in Description above assigned to shepherd your PR.
  • [Author] Add the <issue-id> in the Description above for the associated GitHub Issue.
  • [ ] [Author] Ensure wikize_refs.py -i <base>.md is run and commit (if using wikize_refs.py).
  • [Author] Inspect the content in the *.md file(s) as rendered in GitHub for this PR.
  • [EB Mem] Assign this PR to the EB member <eb-member-id>.
  • [EB Mem] Assign this PR to the author of the PR <pr-author-id>.
  • [EB Mem] Add one or more Reviewers.
  • [EB Mem] Add label content: <content-type> for the type of contribution.
  • [EB Mem] Add to Project Content Development (see Content Development).
  • [EB Mem] Add meta-data to the *.md file(s) (set Publish: yes).
  • [EB Mem] Add label preview (so PR branch will be merged to 'preview' branch and watch for possible merge failures).
  • [EB Mem] Rebuild preview site and confirm new content is there, renders correctly and is returned in searches.
  • [Author] Make any final changes to the PR based on feedback.
  • [ ] [Author] Ensure wikize_refs.py -i <base>.md is run and commit (if using wikize_refs.py).
  • [EB Mem] Rebuild preview site and re-confirm content looks correct.
  • [EB Mem] Ensure at least one reviewer signs off on the final changes.
  • [EB Mem] Move the PR to "Ready to Publish" in Content Development.
  • [EB Mem] Leave comment and @mention @betterscientificsoftware/bssw-maint (BSSw Maint) asking to carry out final publication steps.
  • [BSSw Maint] Verify that all needed files are present in the PR (article, images, updates to Site/Homepage.md carousel and/or Site/Announcements/Announcements.md as appropriate).
  • [BSSw Maint] Merge PR. (Should automatically move to "Done" in Content Development.)
  • [BSSw Maint] Verify new contribution shows up on bssw.io as expected.

NOTE:

  • Checklist items prefixed with [Author] are expected to be performed by the author of the PR or can be performed by the author.
  • Checklist items prefixed with [EB Mem] must be performed by a BSSw.io Editorial Board (EB) Member.
  • Checklist items prefixed with [BSSw Maint] must be performed by someone in the @betterscientificsoftware/bssw-maint team (hint: type @, b, s, s, w, -, m to auto-complete to @betterscientificsoftware/bssw-maint).

@bartlettroscoe bartlettroscoe added the content: article-deprecated A label for article content. This was deprecated in Feb 2024 after we established blog tracks. label Nov 3, 2022
Copy link
Member

@markcmiller86 markcmiller86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just added a few comments. Not sure where you want to take it but maybe they are helpful.


* Why we care to measure productivity? => Software estimation, individual developer performance evaluation?

* The number one way of improving productivity is to write less software (see [impl-lean-dev]).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm...carried to its extremes, this would mean we wouldn't write a single line of code and we'd be infinitely productive.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would go along with software reuse.

* The on-going cost of software maintenance is strongly correlated with the size of the code base (see: code complete???).

* Defining productivity by directly measuring the amount of software created disincentivizes solutions that may reuse existing software or refactorings that may actaully result in less overall source code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Developers who remove code (or have a net negative contribution on GitHub) yet maintain or even enhance functionality should be celebrated. Are they?

We don't have good processes for removing obsoleted code. All of our processes are about adding and supporting code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally feel great when I am able to delete a bunch of code that I wrote years ago and can maintain needed functionality. Every line of code deleted is one less line of code to test and maintain.

For example, making a code build faster and have its test suite run faster does not directly improve functionality but can greatly improve future development productivity. (E.g. a single Trilinos PR build takes over 6 wall-clock hours to run, and that is once it has started running. It can take days to get the PR tester to start running the builds.)


Key points to make?

* Why we care to measure productivity? => Software estimation, individual developer performance evaluation?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always be improving processes is another reason to care. If we don't know how much something costs, we can't begin to identify where we could reduce cost (e.g. improve productivity).

What about how we (in the HPC/CSE space anyways) don't really seem to be charged with just writing code or just designing or just testing or just product development or just support. All of us wear all of these hats and frequently context switch them multiple times in any given day making the problem of measuring cost of any one that much harder.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, we can measure things that we know are associated with waste and work to eliminate those things. And context switching and relearning is a major form of waste.

@bartlettroscoe bartlettroscoe added this to In progress in Content Development Nov 3, 2022
@markcmiller86
Copy link
Member

I am very sorry @bartlettroscoe I am apparently supposed to be shepharding this and its wholly fallen off my radar. My sincere apologies.

I think we have a good conversation in the PR here but I think the article is completed, correct?

@markcmiller86
Copy link
Member

Ah, ok, I see now its still in development and consists now mainly of notes to self about what to include.

@bartlettroscoe
Copy link
Member Author

Ah, ok, I see now its still in development and consists now mainly of notes to self about what to include.

Correct

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
content: article-deprecated A label for article content. This was deprecated in Feb 2024 after we established blog tracks.
Projects
Content Development
  
In progress
Development

Successfully merging this pull request may close these issues.

The myth of developer productivity
2 participants