-
Notifications
You must be signed in to change notification settings - Fork 90
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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]). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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? |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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? |
Ah, ok, I see now its still in development and consists now mainly of notes to self about what to include. |
Correct |
@bartlettroscoe : Is this active? Else consider moving it out of in-progress? Maybe draft PR? |
Yes. At the last bssw.io EB meeting, @markcmiller86 and I discussed collaborating on a original/blog article on this topic next month. |
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
@mention
the BSSw.io editorial board member@<eb-member-id>
in Description above assigned to shepherd your PR.<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)*.md
file(s) as rendered in GitHub for this PR.<eb-member-id>
.<pr-author-id>
.content: <content-type>
for the type of contribution.Content Development
(see Content Development).*.md
file(s) (setPublish: yes
).preview
(so PR branch will be merged to 'preview' branch and watch for possible merge failures).[ ] [Author] Ensurewikize_refs.py -i <base>.md
is run and commit (if using wikize_refs.py).@betterscientificsoftware/bssw-maint
(BSSw Maint) asking to carry out final publication steps.NOTE:
@betterscientificsoftware/bssw-maint
team (hint: type@
,b
,s
,s
,w
,-
,m
to auto-complete to@betterscientificsoftware/bssw-maint
).