Aanpassen of opnieuw opbouwen van grote projecten

[djluc]

Gebaseerd op ervaring in diverse projecten en diverse artikelen over dit onderwerp lijkt het me een zeer relevante discussie om onder de developers maar zeker om met de groep managers en beheerders die actief is in /14 te kijken naar het onderwerp:

De kwestie: Opnieuw beginnen of niet?
Wanneer begin je met het from scratch ontwikkelen van een stuk software en wanneer doe je dit juist niet en ga je doorontwikkelen en verbeteren op basis van de bestaande codebase. Dus stap voor stap ofwel refactoring.

Veelal wordt al reden genoemd voor een rebuild dat het behouden van legacy software meer werk kost dan oplevert. In de praktijk zien we echter ook vaak dat het herbouwen toch op een hoop problemen stuit op zowel technisch vlak als business wise qua tijdsduur van oplevering en kosten.

Bekende artikelen en documentatie

Over dit onderwerp zijn een hoop artikelen geschreven waaronder deze vrij bekende post: http://www.joelonsoftware.com/articles/fog0000000069.html

Tevens zijn er goede boeken geschreven over het ontwikkelen van software en hoe daarbij om te gaan met legacy software zoals: http://www.amazon.com/dp/0131177052/

Ik ben benieuwd naar:

Jullie ervaringen met het nemen van dit besluit en de uiteindelijke resultaten. Heeft het inderdaad geholpen of is het een zwaar project geworden met veel issues en overwachte zaken?

Is de code ook daadwerkelijk beter geworden of ben je juist een hoop bugfixes verloren waardoor het geheel weer een tijd bugfixes moet krijgen om even stabiel te worden?

Dit is bedoeld als een open discussie over een besluit wat velen hier zullen maken of reeds gemaakt hebben. Op basis van ervaring dus maar de theorie en onderzoeken die het besluit ondersteunen zijn uiteraard ook zeer relevant en van grote toegevoegde waarde indien beschikbaar!

[Hydra]

Wanneer begin je from scratch: als het project unrecoverable is en het (om welke reden danook) goedkoper is om een rewrite te doen dan de huidige software te fixen / uit te breiden.

[alt-92]

offtopic:
Wel grappig als Joel zegt dat je eigenlijk niet aan rebuild from scratch moet beginnen, maar voor reuse of met rust laten van bugvrije maar minder gelikte code iedereen over een bedrijf uit Redmond heenvalt

[Maniacs]

In het geval van grote projecten zou je eigenlijk enkel van scratch moeten beginnen indien je van ontwikkeltaal wisselt. In alle andere gevallen is het veel verstandiger de legacy code stap voor stap te upgraden.

Grote projecten hebben een grote doorlooptijd. Dit houdt dus in dat tijdens een totale rewrite er geen functionele wijzigingen kunnen worden doorgevoerd, of ze moeten op zowel het oude als het nieuwe systeem worden ingevoerd. Dit brengt uiteraard weer extra kosten met zich mee.
Ook voorkom je lastige situaties m.b.t. tijds/budget overschijden van de planning en/of budget: Wat doe je als bedrijf als je project wat is geschat op 1 jaar werk en 50 miljoen euro 1,5 jaar lijkt te gaan duren en 75 miljoen moet gaan kosten? Is het die investering nog waard?

Al deze problemen voorkom je door het oude systeem stapsgewijs te upgraden naar een systeem wat qua techniek op vergelijkbaar niveau van een nieuwbouw systeem zit. Hiermee verdeel je het risico van een big-bang scenario naar meerdere beheersbare iteraties. Ook dan hou je uiteraard het risico van budget/planning overschrijding, maar de tot dan toe gedaane aanpassingen zijn geen weggegooid geld.

Kortom: de financiele risico's van een totale rewrite van een grote applicatie zijn dus nagenoeg altijd groter als van een gecontroleerde upgrade.

[djluc]

Hydra schreef op zaterdag 20 oktober 2012 @ 18:51:
Wanneer begin je from scratch: als het project unrecoverable is en het (om welke reden danook) goedkoper is om een rewrite te doen dan de huidige software te fixen / uit te breiden.

Dat is inderdaad een veel gezien voorbeeld. Het probleem is vaak dat het inschatten van de goedkoopste optie erg lastig blijkt. De hoeveelheid bugfixes die gedaan zijn in het verleden zijn bij legacy projecten vaak niet goed zichtbaar. Het bepalen is dus een lastige kwestie verwacht ik. Als je een complete bugtracker hebt zou je deze wel kunnen gebruiken, dus nieuwe software ontwikkeling doen en dan alle oude bugs proberen na te bootsen om te zien of ze in de nieuwe versie niet voorkomen.

alt-92 schreef op zaterdag 20 oktober 2012 @ 19:32:

offtopic:
Wel grappig als Joel zegt dat je eigenlijk niet aan rebuild from scratch moet beginnen, maar voor reuse of met rust laten van bugvrije maar minder gelikte code iedereen over een bedrijf uit Redmond heenvalt

Hij is wel interessant en relevant eigenlijk. In principe zien we de code natuurlijk niet maar het legacy verhaal is wel erg van toepassing. Inderdaad worden steeds complete nieuwe versies gezien als goed maar stabiliteit is blijkbaar ook erg gewaardeerd.

[Hydra]

djluc schreef op woensdag 24 oktober 2012 @ 15:14:
Dat is inderdaad een veel gezien voorbeeld. Het probleem is vaak dat het inschatten van de goedkoopste optie erg lastig blijkt. De hoeveelheid bugfixes die gedaan zijn in het verleden zijn bij legacy projecten vaak niet goed zichtbaar. Het bepalen is dus een lastige kwestie verwacht ik. Als je een complete bugtracker hebt zou je deze wel kunnen gebruiken, dus nieuwe software ontwikkeling doen en dan alle oude bugs proberen na te bootsen om te zien of ze in de nieuwe versie niet voorkomen.

Ik begrijp je punt niet. Het gaat niet om oude bugfixes, het gaat om te kosten van toekomstige aanpassingen. Als het meer kost om die aanpassingen in het huidige systeem te doen dan om het hele systeem te herschrijven, dan is het feasable. En die dingen kun je best aardig inschatten.

[D-Raven]

Hydra schreef op woensdag 24 oktober 2012 @ 15:18:
[...]


Ik begrijp je punt niet. Het gaat niet om oude bugfixes, het gaat om te kosten van toekomstige aanpassingen. Als het meer kost om die aanpassingen in het huidige systeem te doen dan om het hele systeem te herschrijven, dan is het feasable. En die dingen kun je best aardig inschatten.

Dat klopt wel. Alleen is het niet zo simpel.
Een legacy applicatie zit vaak vol met "puisten", allerlei rare code constructies welke bugfixes verhullen waarvan het niet direct duidelijk is dat het bugfixes zijn. Op het moment dat je een serieuze legacy applicatie vanaf scratch opnieuw gaat bouwen loop je altijd weer tegen dingen aan van: Owja, daarom deden we dit hier zo.
Het is juist die dingen wat het inschatten van evt kosten en doorlooptijd zo moeilijk maakt.

[Hydra]

D-Raven schreef op woensdag 24 oktober 2012 @ 15:32:
Dat klopt wel. Alleen is het niet zo simpel.
Een legacy applicatie zit vaak vol met "puisten", allerlei rare code constructies welke bugfixes verhullen waarvan het niet direct duidelijk is dat het bugfixes zijn. Op het moment dat je een serieuze legacy applicatie vanaf scratch opnieuw gaat bouwen loop je altijd weer tegen dingen aan van: Owja, daarom deden we dit hier zo.
Het is juist die dingen wat het inschatten van evt kosten en doorlooptijd zo moeilijk maakt.

Tja, moeilijk. Aangezien het sowieso onmogelijk is voor dit soort projecten een 100% correcte inschatting te maken houd je daar een slag om de arm en giet je er in de inschatting een risicofactor overheen als er veel van dit soort bekende onbekendheden inzitten.

Geen enkele form van functionele documentatie? Hoppa, factor 2.

[chime]

Eigenlijk enorm moeilijk te zeggen.

Iets herbouwen is makkelijk gezegd, maar vaak loopt het al fout met het verzamelen van de gegevens van wat het bestaande systeem nu eigenlijk wel kan.

Eigenlijk loop je gewoon aan tegen dezelfde problemen als met een nieuw project.


Maar ik snap de scope van je vraag niet direct.
Want over het algemeen kom je niet zomaar in een situatie dat je moet kiezen tusen rewrite of delete en rebuild.

Als je meer tijd kwijt bent met het uitzoeken en rommelen in de bestaande code als features/bugfixes uit te voeren => dan kan dat een indicatie zijn.
Maar zelfs dan nog is het herschrijven van 1 klasse / 1 module dan vaak al voldoende.

Echt volledig vanaf 0 lijkt me eerder in de volgende situaties:
- wijziging van technologie (taal, framework dat zwaar gebruik wordt)
- echt nieuwe schone lei -> maar dan ook nieuwe business requirements gebaseerd op wat de mensen echt nodig hebben en niet wat in het oude systeem aanwezig is (let op: deze oefening kan bij een migratie bv. je nieuwe systeem veel slanker maken)
- het is zo'n rommel geworden dat je er niets meer mee bent, maar dan gaan we dus eigenlijk naar het vorige puntje.

[Hydra]

chime schreef op donderdag 25 oktober 2012 @ 08:56:
Iets herbouwen is makkelijk gezegd, maar vaak loopt het al fout met het verzamelen van de gegevens van wat het bestaande systeem nu eigenlijk wel kan.

Als er geen goeie documentatie is dan duik je dus in de code. Dit is niet moeilijk, het is reteveel werk en saai bovendien, dus wordt vaak geroepen dat het 'moeilijk' is.

[chime]

Hydra schreef op donderdag 25 oktober 2012 @ 10:25:
[...]


Als er geen goeie documentatie is dan duik je dus in de code. Dit is niet moeilijk, het is reteveel werk en saai bovendien, dus wordt vaak geroepen dat het 'moeilijk' is.

Reteveel + saai = veel kans op fouten => moeilijk
Reteveel + saai = duur en veel werkuren => moeilijk om het te verkopen aan het management

[Hydra]

Tja, laten we het erop houden dat ik een andere definitie van "moeilijk" heb.

[djluc]

Hydra schreef op woensdag 24 oktober 2012 @ 15:18:
[...]


Ik begrijp je punt niet. Het gaat niet om oude bugfixes, het gaat om te kosten van toekomstige aanpassingen. Als het meer kost om die aanpassingen in het huidige systeem te doen dan om het hele systeem te herschrijven, dan is het feasable. En die dingen kun je best aardig inschatten.

Vaak zijn dat soort bugfixes voor vreemde scenarios. Situaties die niet altijd maar soms voorkomen door een samenloop van omstandigheden. Bijvoorbeeld een nog vrij duidelijk voorbeeld:

De facturen uitgeleverd door het facturatiepakket bevatten altijd minimaal 1 factuurregel maar in een oudere versie is dat niet het geval. Mocht je op een gegeven moment historische facturen gaan importeren blijkt je model niet meer te kloppen.

Voor kleine puntjes en komma's wordt het nog erger. Dat is wat ik bedoel, het voorbereiden is vrijwel niet te doen en kost inderdaad zeer veel tijd.

D-Raven schreef op woensdag 24 oktober 2012 @ 15:32:
[...]
Dat klopt wel. Alleen is het niet zo simpel.
Een legacy applicatie zit vaak vol met "puisten", allerlei rare code constructies welke bugfixes verhullen waarvan het niet direct duidelijk is dat het bugfixes zijn. Op het moment dat je een serieuze legacy applicatie vanaf scratch opnieuw gaat bouwen loop je altijd weer tegen dingen aan van: Owja, daarom deden we dit hier zo.
Het is juist die dingen wat het inschatten van evt kosten en doorlooptijd zo moeilijk maakt.

Die stukjes code inderdaad, je gooit ervaring weg maar anders zit je tussen de oude code te rommelen. Het is vaak een lastige keuze in de praktijk.

Hydra schreef op donderdag 25 oktober 2012 @ 10:25:
[...]
Als er geen goeie documentatie is dan duik je dus in de code. Dit is niet moeilijk, het is reteveel werk en saai bovendien, dus wordt vaak geroepen dat het 'moeilijk' is.

Dat is inderdaad wat er dan moet gebeuren. Dat het niet leuk is: Zeker. Het lastige wat je ziet is dat het opstellen van een offerte en/of begroting op basis van een bestaande applicatie gebeurt. Vaak is het voortraject minder qua uren dan de opdracht zelf. Maar je hebt inderdaad totaal gelijk, het moet gebeuren anders komt het niet goed.