WIP: Short Article: The Myth of Developer Productivity #1484
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| # Myth of Developer Productivity | ||
|
|
||
| <!--deck text start--> | ||
| The ability to directly effectively measure individual software developer productivity has eluded software developers for decades. Why is this so hard and what are the alternatives? | ||
| <!--deck text end--> | ||
|
|
||
| #### Contributed by [Roscoe A. Bartlett](https://github.com/bartlettroscoe), [Mark C. Miller](https://github.com/markcmiller86) | ||
|
|
||
| #### Publication date: December, ??? 2022 | ||
|
|
||
| Here are the references I want to include: [myth-dev-prod], [cant-meas-prod], [kanban-and-scrum], [impl-lean-dev] (NOTE: We need a CC article for [impl-lean-dev].) | ||
|
|
||
| Key points to make? | ||
|
|
||
| * 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. 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. This would go along with software reuse. |
||
|
|
||
| * The cost of software maintenance is often several times much higher than the cost to create the software in the first place. | ||
|
|
||
| * 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. 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. 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.) |
||
| * Cover some of the arguments made in the comments of https://github.com/betterscientificsoftware/bssw.io/issues/1341 | ||
|
|
||
| <!--References--> | ||
|
|
||
| [myth-dev-prod]: https://nortal.com/us/blog/the-myth-of-developer-productivity/ "The myth of developer productivity" | ||
| [cant-meas-prod]: martinfowler.com/bliki/CannotMeasureProductivity.html "Cannot Measure Productivity" | ||
| [kanban-and-scrum]: bssw.io/items/kanban-and-scrum-making-the-best-of-both "Kanban and Scrum: Making the best of both" | ||
| [impl-lean-dev]: https://bartlettroscoe.github.io/reading-list/#implementing_lean_software_development_2007 "Implementing Lean Software Development" | ||
|
|
||
|
|
||
| <!--- | ||
| Publish: yes | ||
| Pinned: no | ||
| Topics: Software engineering, refactoring, design, peer code review | ||
| RSS update: 2021-10-20 | ||
| ---> | ||
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.