Diminishing Returns in software development and maintenance | Javalobby

Diminishing Returns in software development and maintenance | Javalobby
Building Real Software: Diminishing Returns in software development and maintenance

Diminishing returns

From Wikipedia, the free encyclopedia
Diminishing returns - Wikipedia, the free encyclopedia

• In economics, diminishing returns (also called diminishing marginal returns) is the decrease in the marginal (per-unit) output of a production process as the amount of a single factor of production is increased, while the amounts of all other factors of production stay constant.
• The law of diminishing returns (also law of diminishing marginal returns or law of increasing relative cost) states that 
• In all productive processes, adding more of one factor of production, while holding all others constant, will at some point yield lower per-unit returns.[1] 
• The law of diminishing returns does not imply that 
• Adding more of a factor will decrease the total production, 
• A condition known as negative returns, though in fact this is common.
• Example, 
• Fertilizer
• The use of fertilizer improves crop production on farms and in gardens; 
• But at some point, adding more and more fertilizer improves the yield less per unit of fertilizer, 
• And excessive quantities can even reduce the yield. 
• Workers to a job
• A common sort of example
• Adding more workers to a job, such as assembling a car on a factory floor. 
• At some point, adding more workers causes problems such as getting in each other's way, or workers frequently find themselves waiting for access to a part. 
• In all of these processes, producing one more unit of output per unit of time will eventually cost increasingly more, due to inputs being used less and less effectively.

• The law of diminishing returns is a fundamental principle of economics.[1] It plays a central role inproduction theory.

Diminishing Returns in software development and maintenance | Javalobby

• When you add a person to a team, 
• A short-term hit as 
• The rest of the team slows down to bring the new team member up to speed and adjusts to working with another person, making sure that they fit in and can contribute. 
• A long-term cost. 
• More people means more people who need to talk to each other (n x n-1 / 2), which means more opportunities for misunderstandings and mistakes and misdirections and missed handoffs, more chances for disagreements and conflicts, more bottleneck points.

Other possible way for diminishing returns

Pushing too hard in one direction, depending too much on any tool or practice, will eventually yield diminishing returns. This applies to:

• Manual functional and acceptance testing
• Test automation
• Any single testing technique
• Code reviews
• Static analysis bug finding tools
• Penetration tests and other security reviews

Is it bad to have an “Obsessive Refactoring Disorder”?

personality - Is it bad to have an "Obsessive Refactoring Disorder"? - Programmers - Stack Exchange

Refactoring is generally a good idea if it does not interfere with your schedule and does not negatively impact your work. Still, I believe it is a matter of priorities.

• The goal is not to write the perfect code.
• The goal is to deliver a working product.

The larger a project is, the less chances there are to keep the codebase tidy and perfect. Just accept some imperfection ratio and watch out not to cross it. Minor deviations are okay if they're not potentially dangerous.

Obsessive Compulsive/Refactoring Disorder - GameDev.net
management - How to handle coworker with "obsessive refactoring disorder" - Programmers - Stack Exchange