DETTE TECHNIQUE ET QUALITÉ LOGICIELLE
Quote by Ward Cunningham in 1992: “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." The concept does not mean that debt should never be incurred. Just as leverage can help a company when used correctly, a quick solution can mean a faster time to market in software development. In addition, technical debt is not just poor code. Bad code is bad code, and technical debt can result from the work of good programmers under unrealistic project constraints.”
Quote by Ward Cunningham in 1992: “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." The concept does not mean that debt should never be incurred. Just as leverage can help a company when used correctly, a quick solution can mean a faster time to market in software development. In addition, technical debt is not just poor code. Bad code is bad code, and technical debt can result from the work of good programmers under unrealistic project constraints.”
SQALE is a quality model and method focusing on managing technical debt
Technical debt measures the effort (time and cost) required to increase the internal software quality
Explain that these ideas of social debt (and examples of community smells) have not been studied yet at the software ecosystem level.
Explain that these ideas of social debt (and examples of community smells) have not been studied yet at the software ecosystem level.
Use the “community smell” of “organisational silo” as a transition to the next slide, to explain that members of the “research community” should not stay within their own silo either (their own specific research discipline), but should communicate and colloborate with (and learn from) researchers from other disciplines.
Quote by Ward Cunningham in 1992: “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." The concept does not mean that debt should never be incurred. Just as leverage can help a company when used correctly, a quick solution can mean a faster time to market in software development. In addition, technical debt is not just poor code. Bad code is bad code, and technical debt can result from the work of good programmers under unrealistic project constraints.”
Quote by Ward Cunningham in 1992: “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." The concept does not mean that debt should never be incurred. Just as leverage can help a company when used correctly, a quick solution can mean a faster time to market in software development. In addition, technical debt is not just poor code. Bad code is bad code, and technical debt can result from the work of good programmers under unrealistic project constraints.”
“The package leftpad essentially contains a few lines of source code but has thousands of dependent projects, including Node and Babel.
When its developer decided to unpublish all his modules for npm, this had important consequences, “almost breaking the internet “
March 2016: Unexpected removal of left-pad caused > 2% of all packages to break (> 5,400 packages)
RubyGems, November 2010: Release 0.5.0 of i18n broke dependent package ActiveRecord, transitively required by>5% of all packages (930)
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Transitive dependencies are a problem, especially since dependency monitoring tools typically only consider direct dependencies.
Breaking changes = backward incompatible changes that are not announced as such. If semantic versioning is used, breaking changes should only arise in "major" releases.