Stai sfogliando l'archivio delle categorie per la categoria ‘Software’ .
In projects – especially software ones – one can perform any activity in the best possible way or degenerate to a level that barely works: this degeneration introduces Technical Debt whose interests shall be repaid later, during the evolution of the product, int arms of an extra maintenance effort.
The concept of technical debt is best explained as:
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.
-Ward Cunningham
I am currently reading some work about TD and so I am also trying to place individual tiles into a big picture puzzle. Currently there is much interest around this idea and a working group on the topic has been created.
So, this is how I figured it out by myself:
Any time we degrade the quality of our work we introduce new issues (e.g. defects, hard-to-understand code, tangled design etc.) that will induce extra maintenance effort, i.e. additional costs.
The interest we pay on debt corresponds to the difference between the present value of future cost of extra maintenance minus the cost we save by choosing a less than optimal practice.
Did I simplify it too much or made it too complex?
Oggi guardando il portale del repository di ateneo delle pubblicazioni (PORTO) ho scoperto la possibilità di esportare i dati in vari formati.
La mia attenzione è stata attirata da un formato in particolare: JSON. Si tratta di formato, sostanzialmente alternativo a XML, che è definito come un sottoinsieme di Javascript / ECMAScript. Mi è venuta la curiosità di verificare quanto sia facile integrare in una pagina i dati forniti in JSON, in sostanza realizzando una sorta di mash-up che preleva dati da una sorgente esterna.
….la risposta è facilissimo, provare per credere.
