Modell för mjukvaruutveckling
Håller på att ta mig igenom en artikel med filosofisk ton som beskriver en modell för utveckling av mjukvara. Författaren ser mjukvaruutveckling som ett spel, i spelteoretisk mening. Intressant!
The end of software engineering
Artikeln har tydligen publicerats i denna vetenskapliga tidsskrift:
The end of software engineering
Artikeln har tydligen publicerats i denna vetenskapliga tidsskrift:
En liten godbit innifrån:
Thus, unlike a rock-climbing trip, a software project has two goals:
* To deliver the system;
* To set up for the next game.
The full evaluation of the project therefore includes, first, whether the system was delivered, and second, to what extent an advantageous position was created for the next game.
These two goals compete for resources. The team can deliver the system more quickly if the system will not have to be extended in the future. (It can deliver the system much, much sooner if bugs will not have to be fixed!) Or, the team can set in place a better software architecture and more training and documentation for their successors at the expense of delaying or even preventing the current delivery.
Jäkligt vist sagt... Ett mjukvaruprojekt har två mål i det mest abstrakta: att ge ett resultat (programmet) i slutet av projektet och efterlämna en källkodsbas som är bra att bygga vidare på! Det är detta som är dilemmat man upplever dagligen som programmerare: kunden vill bara ha så snart som möjligt, och man kan koda ihop skräp snabbt också, men man själv funderar på hur kan kan skriva så enkelt som möjligt, så det går att hantera koden i framtiden...
Thus, unlike a rock-climbing trip, a software project has two goals:
* To deliver the system;
* To set up for the next game.
The full evaluation of the project therefore includes, first, whether the system was delivered, and second, to what extent an advantageous position was created for the next game.
These two goals compete for resources. The team can deliver the system more quickly if the system will not have to be extended in the future. (It can deliver the system much, much sooner if bugs will not have to be fixed!) Or, the team can set in place a better software architecture and more training and documentation for their successors at the expense of delaying or even preventing the current delivery.
Jäkligt vist sagt... Ett mjukvaruprojekt har två mål i det mest abstrakta: att ge ett resultat (programmet) i slutet av projektet och efterlämna en källkodsbas som är bra att bygga vidare på! Det är detta som är dilemmat man upplever dagligen som programmerare: kunden vill bara ha så snart som möjligt, och man kan koda ihop skräp snabbt också, men man själv funderar på hur kan kan skriva så enkelt som möjligt, så det går att hantera koden i framtiden...
Kommentarer
Trackback
