-
Notifications
You must be signed in to change notification settings - Fork 26
Productivity
Warning: Wiki should not be edited directly. Edit the files in the ./wiki/ folder instead and make a PR.
The first thing to read would be our preprint Long-term Productivity for Long-term Impact. Lays out our thinking.
The point of this page is to continue the evolution of those ideas.
One of the odd things is the measure of output: user-satisfaction and knowledge created. What are the units? And is the unit of output correct? Current conclusion: no.
New thinking: the measure of output should be 'value produced'. Value for users and values for producers. How to combine these into overall value is also tricky -- multiplication is not good. (Brynjolfsson and Hitt (1998) say the same thing about value: "Properly measured, output should include not just the number of widgets coming out of a factory, or the lines of code produced by a programming team, but rather the value created for consumers.")
Note that 'value' should not be equated with money. Money is a proxy for tradable-value in some kind of market. It has severe bounds as a unit. The simplest example in software is open source projects, where often no money at all is directly involved. This is the reason that the proxy for value for users was originally chosen as 'satisfaction'.
The reason one downloads or buys a piece of software is because it provides some value to us. Even for a game - the entertainment it provides is indeed something regarded as 'valuable' to the person experiencing it. Sometimes that value is indirect, as the software might simply be necessary to do one's job (such as Excel). A browser provides me value by enabling me to go to various web sites, which is now a necessity in modern life. Other software (like a programmer's editor) provides me value by increasing my efficiency.
Similarly, the value sources for the producers of software is myriad. One might be tempted to reduce it to money in the case of commercial companies; the problem with that remains that it is a lagging indicator. In other words, current investments in (say) process improvements might not have a visible payoff for years. This also disregards other factors, like morale. Many studies have established that happy developers are more 'productive'. And this completely falls apart for productivity of hobbyists. So we need to dig deeper to find the 'sources of value' that exist.
- Software productivity: a framework of study and an approach to reusable components which leads to forward citations.
ToDo:
- link up lots of the recently found literature
- add some definitions that others have used
- Home
- Getting Started
- Documentation (of Drasil specifics)
- Design
-
Readings
- Drasil Papers and Documents
- Related Work and Inspiration
- Writing Documentation
- Compression as a Means to Learn Structure
- Glossary, Taxonomy, Ontology
- Grounded Theory
- Model Driven Scrapbook
- Model Transformation Languages
- ODE Definitions
- The Code Generator
- Suggested Reading
- Sustainability
- Productivity
- Reuse
- Formal Concept Analysis
- Generative Programming
- Software Documentation
- Units and Quantities
- Misc.
- WIP Projects