[Algemeen] Werk van anderen overnemen

[Varienaja]

Hey,

Mijn bedrijf is gefuseerd met een ander bedrijf. Dat andere bedrijf had vroeger een ontwikkelteam van 7 man, maar ten tijde van de fusie was er nog maar één programmeur van over. Na een tijdje is ook deze man weggegaan, en ik heb de opdracht gekregen om alle sources van het 'andere' bedrijf onder mijn hoede te nemen.

Als overdrachtsdocumentatie kreeg ik een documentje van een paar pagina's met een zeer globaal overzicht van de werking en functie van de verschillende modules. En een rijtje instellingen die benodigd zijn voor het functioneren van de software. Ik heb verder nog twee dagen met die jongen doorgebracht, waarin hij mij allerlei dingen heeft laten zien, en uitgelegd.

Tot zo ver leek het mij wel in orde. Maar toen ik de software op mijn eigen pc aan de praat wilde krijgen, bleek het niet te werken (opstarten, AccesViool, en weg was ie weer). Ik heb nu een aantal werkdagen zitten prutsen, maar er is in het hele bedrijf maar 1 pc te vinden waarop de boel wil compileren. Verder zijn er geen ontwerpen, geen functionele eisen, geen handleidingen, de code is straightforward (met andere woorden: enorme lappen shitzooi zonder veel commentaar).

Mijn vraag: wat vinden jullie daar nu van? Heeft iemand anders weleens software overgenomen, en hoe ging dat dan?

[D2k]

maak het opnieuw
in de tijd dat je nu bezig bent de problemen op te lossen had je ws al een werkend iets kunnen maken

note: geen proffessionele ervaring mee

[Varienaja]

D2k schreef op 22 januari 2003 @ 13:43:
maak het opnieuw
in de tijd dat je nu bezig bent de problemen op te lossen had je ws al een werkend iets kunnen maken

Het is wel prut waar 7 man jarenlang hun brood mee verdiend hebben, dat maak je niet opnieuw met een budget van 240 uur.

Bovendien heeft ons 'eigen' bedrijf eenzelfde soort software. Mijn chef maakt zich er ook kwaad over dat we niet daarop overstappen.

[whoami]

[nohtml]

D2k schreef op 22 January 2003 @ 13:43:
maak het opnieuw
in de tijd dat je nu bezig bent de problemen op te lossen had je ws al een werkend iets kunnen maken

Tja, als het slechts een klein pakket/programma is , is dat zeker een optie. Als het echter over 1000den, 10000den regels code gaat, waar heel het bedrijf al mee werkt, is dat niet zo vanzelfspreken.

Persoonlijk heb ik het nog niet meegemaakt dat ik de 'hoede' kreeg over de code die anderen geschreven hadden en dat die 'anderen' het bedrijf verlaten hadden. (gelukkig maar). Wel heb ik al verscheidene keren aanpassingen moeten doen aan source-code, maar toen waren de oorspronkelijke auteurs wel nog in het bedrijf werkzaam.

Zo zie je maar wat het belang is van goede documentatie, goede requirements en analyse documenten. Die documenten vind ik veel belangrijker dan commentaar in de code.

[mulder]

Misschien moet je de applicatie langzaam 'muteren' in een eigen applicatie, zo nu en dan een stuk verbouwen. (bv als je een aanpassing maakt/functionaliteit toevoegt)

[Atari Paul]

Tja, wat zal ik zeggen...

Ik heb helaas dit soort praktijken wel vaker meegemaakt en waar het meestal wel op neer komt is dat een volledig nieuw ontwerp en bouw de beste oplossing is.
Zelfs als dit veel tijd kost, want code van anderen doorspitten zonder behoorlijke documentatie is geen doen.

Als de code 'bugfree' is dan zou ik het laten draaien.
Of is het pakket zo klein dat je er denkt uit te kunnen komen in korte tijd ?
Anders zou ik zeker proberen om samen met je baas over te stappen naar dat pakket wat jullie zelf in huis hebben.

[Varienaja]

Don Facundo schreef op 22 januari 2003 @ 13:55:
Misschien moet je de applicatie langzaam 'muteren' in een eigen applicatie, zo nu en dan een stuk verbouwen. (bv als je een aanpassing maakt/functionaliteit toevoegt)

Dit is geen hobby-klusje. Ik heb (krijg) helemaal geen tijd voor zulke fratsen. Bovendien heb ik door alle problemen die ik tot nu toe heb ontdekt helemaal geen zin meer om nog veel energie in die meuk te steken.

[Freee!!]

Zolang er geen fouten in zitten rustig laten draaien, bij foutmeldingen (van klanten) deze oplossen en zo kalm aan de hele zooi leren kennen. Lastig voor je dat alles maar op één PC compileert, zou daar eerst eens naar kijken.

Wat betreft het overnemen van programma's die door een ander geschreven zijn (bij voorkeur zonder documentatie of nog liever met niet kloppende documentatie ), dat heb ik al een paar keer gedaan (30 jaar oude code soms) en is nog steeds niet mijn favoriete bezigheid.

[Creepy]

Ik heb wel wat ervaring met overnemen van de code van anderen

In het begin loop je bijna altijd te vloeken.. omdat het anders in elkaar zit dan jij gewilt zou hebben... Gewoon rustig je het programma, opzet en code eigen maken.. en inzicht krijgen waar de grootste problemen kunnen onstaan e.d.

Mochten er dan grote problemen voordoen, kijk dan eerst of je ze kan oplossen. Mocht dit te veel tijd kosten -> Rewrite van dat deel. Echt.. een rewrite (zeker als je zeker weet dat je het zelf opnieuw beter kan) kost over het algemeen MINDER tijd dna aan te kloten en niet snappen waarom het nog niet werkt.

Ik heb hier nu twee keer gehad dat ik code moest overnemen van een collega die vertrok. 1 keer ging dit prima... tuurlijk heb ik toen lopen vloeken op z'n code.. maar na verloop van tijd snap je de boel en kan ik er mee verder. Een andere keer heb ik in 5 dagen 1 bug gefixt. 3 dagen gezocht.. gevloekt, getierd etc. 2 dagen besteet een een rewrite van dat deel, en alsnog de bug gefixt dankzij de rewrite.

[mulder]

Varienaja schreef op 22 January 2003 @ 14:11:
[...]
Dit is geen hobby-klusje. Ik heb (krijg) helemaal geen tijd voor zulke fratsen. Bovendien heb ik door alle problemen die ik tot nu toe heb ontdekt helemaal geen zin meer om nog veel energie in die meuk te steken.

Dat is idd hoe het 9 van de 10 keer gaat, ik zelf probeer zelf altijd de oorspronkelijke code zoveel mogelijk intact te houden, maar soms is het prettiger/verstandiger een stuk opnieuw te schrijven.... En hobbyklusjes programmeer ik al heel lang niet meer

[Varienaja]

Mr. Liu schreef op 22 januari 2003 @ 14:12:
Zolang er geen fouten in zitten rustig laten draaien, bij foutmeldingen (van klanten) deze oplossen en zo kalm aan de hele zooi leren kennen. Lastig voor je dat alles maar op één PC compileert, zou daar eerst eens naar kijken.

Ik heb een lijst liggen van 4 A4-tjes, met daarop punten die verbeterd of nieuw gebouwd moeten worden. Ze hebben me gevraagd om een inschatting van de benodigde tijdsduur. Die heb ik op 240uur gezet, maar ik heb daar natuurlijk wel bij gezegd dat het met erg veel natte-vingerwerk gegokt is.

* Varienaja denkt voorzichtig aan een Database-Converter van hun systeem naar het onze

[Verwijderd]

Als de boel al niet eens opstart... mwoah, dan zou ik heel hard bij je baas gaan zeuren.
1. OF om het pakket in de prullenbak te gooien en de klanten te overtuigen van het andere/vergelijkbare pakket te gaan gebruiken.
2. OF meer uren / assistentie te vragen
3. OF mij inhuren

Trouwens, is die Acces Viool niet gewoon een kwestie van ... even vinden waar die fout zit en dan weer verder? Is de code dan dermate klote dat je er helemaal niet mee uit de voeten kan?

/me denkt ook aan een DB-Converter.

[Freee!!]

Varienaja schreef op 22 January 2003 @ 14:18:
[...]
Ik heb een lijst liggen van 4 A4-tjes, met daarop punten die verbeterd of nieuw gebouwd moeten worden. Ze hebben me gevraagd om een inschatting van de benodigde tijdsduur. Die heb ik op 240uur gezet, maar ik heb daar natuurlijk wel bij gezegd dat het met erg veel natte-vingerwerk gegokt is.

* Varienaja denkt voorzichtig aan een Database-Converter van hun systeem naar het onze

Je had als eerste een puntje inleren van die andere programmatuur neer moeten zetten van minimaal 1 dag per programma, nog onafhankelijk van alle aanpassingen. Daarna pas kun je ook maar een vage schatting doen van hoeveel tijd die aanpassingen kosten. Helaas is dit nu wijsheid achteraf, maar dan weet je het voor een volgende keer.

Succes

[curry684]

Varienaja schreef op 22 January 2003 @ 14:18:
[...]
Ik heb een lijst liggen van 4 A4-tjes, met daarop punten die verbeterd of nieuw gebouwd moeten worden. Ze hebben me gevraagd om een inschatting van de benodigde tijdsduur. Die heb ik op 240uur gezet, maar ik heb daar natuurlijk wel bij gezegd dat het met erg veel natte-vingerwerk gegokt is.

Da's al foute boel natuurlijk. Ik zit zelf op het punt een vergelijkbare opdracht aan te nemen voor m'n bedrijf, maar dit soort klussen doe ik alleen op 'uurtje factuurtje', oftewel ik maak schattingen van iedere aanpassing hoe lang ze duren, en als ik op 25-50% van die geschatte tijd erachter kom dat ik ver boven die duratie ga komen escaleer ik het probleem naar de 'opdrachtgever', in dit geval je baas.

Fixed-time en/of fixed-price schattingen op code die je niet door-en-door kent zijn levensgevaarlijk!

[Freee!!]

curry684 schreef op 22 January 2003 @ 14:42:
[...]
Fixed-time en/of fixed-price schattingen op code die je niet door-en-door kent zijn levensgevaarlijk!

Amen.

Voor programmatuur die ik wel goed genoeg ken (door-en-door hoeft nog niet eens), ben ik er dol op. Ik geef gewoon een schatting af die voor de meeste van mijn collega's redelijk te doen is. Als ik het moet doen, houd ik gewoon ongeveer de helft van de tijd over (die ik dus hier besteed )

[Bobco]

Varienaja schreef op 22 January 2003 @ 14:18:
[...]
Ik heb een lijst liggen van 4 A4-tjes, met daarop punten die verbeterd of nieuw gebouwd moeten worden. Ze hebben me gevraagd om een inschatting van de benodigde tijdsduur. Die heb ik op 240uur gezet, maar ik heb daar natuurlijk wel bij gezegd dat het met erg veel natte-vingerwerk gegokt is.

Anderen hebben het ook al gezegd: fixed-time/price uitspraken alleen doen als je precies weet wat er gedaan moet worden en je daar zelf de volledige controle over hebt. Verder is het bij schattingen vaak beter om een range op te geven, met daarbij de uitspraak dat zelfs die range er nog 10tallen procenten naast kan zitten.

Verder is het natuurlijk mogelijk om eerst eens te kijken naar de functionaliteit van de programmatuur en te praten met de gebruikers ervan. Waarvoor gebruiken zij het? Heeft jouw bedrijf al spullen die iets vergelijkbaars doen? Als die laatste vraag met ja kan worden beantwoord zou ik voorstellen om dat pakket tot de standaard te verheffen en de rest zo snel mogelijk weggooien. Je bedrijd is tenslotte ook niet gebaat bij het onderhouden van meerdere stukken software die eigenlijk hetzelfde doen...

[Verwijderd]

Ik persoonlijk heb een bloedhekel aan het lezen van een ander zijn source code, dit komt voornamelijk omdat inderdaad veel programmeurs er een zooitje van maken.
En dan bedoel ik niet het slecht documenteren, maar voornamelijk het maken van eindeloze lappen code met veel herhaling kwa functionaliteit ipv de essentie eruit halen en daar een parameterizeerbare functie van maken.

Of in een object omgeving wrappers om wrappers om wrappers etc te maken.
Of van die zinnige functies die van a naar b naar c terug naar a converteren.

Dit is in mijn optiek vaak het probleem met opensource projecten, er werken meerdere mensen aan met allemaal hun eigen style van werken. Ik snap wel dat dit een noodzakelijk kwaad is, maar het maakt het debuggen of lezen van zulke code onleesbaar.

[TheDane]

misschien niet helemaal vergelijkbaar, maar ik werk in een team van 4 webapplicatie developers. Iedereen heeft z'n eigen codestyle, en ik merk dat ik de code van 1 collega erg moeilijk leesbaar vindt.

We hebben wel een aantal conventies en gemeenschappelijke stijlen, maar af en toe is 't vrij lastig om de code te doorgronden. Hier en daar wat essentiele comments, goede technische specificaties en af en toe elkaar bijpraten helpt enorm.

andermans code aanpassen doe ik niet aan. Misschien hier en daar een kleine functie, maar 9 van de 10 keer herschrijf ik 't gewoon, vooral omdat ik niet zo in 't principe 'black box' vertrouw .. ik wil zelf niet alleen voor 100% zeker weten dat de output precies is wat ik verwacht , maar ook hoe die output gegenereerd wordt.

[Bobco]

TheDane schreef op 22 January 2003 @ 16:45:
misschien niet helemaal vergelijkbaar, maar ik werk in een team van 4 webapplicatie developers. Iedereen heeft z'n eigen codestyle, en ik merk dat ik de code van 1 collega erg moeilijk leesbaar vindt.
[...]
andermans code aanpassen doe ik niet aan. Misschien hier en daar een kleine functie, maar 9 van de 10 keer herschrijf ik 't gewoon, vooral omdat ik niet zo in 't principe 'black box' vertrouw .. ik wil zelf niet alleen voor 100% zeker weten dat de output precies is wat ik verwacht , maar ook hoe die output gegenereerd wordt.

Is je baas daar ook blij mee? Het lijkt me dat je op die manier nogal wat werk dubbel doet, zonder dat het grote voordelen oplevert. Ik weet ook wel dat codestyles behoorlijk van elkaar kunnen verschillen, maar op het moment dat je zelfs de uitvoer van een ander niet vertrouwt en dat zelf nog een keer bouwt lijkt het me lastig om in een team te werken. Hoe doe jij dat als je echt met 10 man iets moet bouwen?

[Config]

TheDane schreef op 22 January 2003 @ 16:45:
Misschien hier en daar een kleine functie, maar 9 van de 10 keer herschrijf ik 't gewoon, vooral omdat ik niet zo in 't principe 'black box' vertrouw .. ik wil zelf niet alleen voor 100% zeker weten dat de output precies is wat ik verwacht , maar ook hoe die output gegenereerd wordt.

Ik snap je beweegredenen voor de volle 180% . Je hebt helemaal gelijk!.

Toch werkt het niet.

Als je een beetje manager hebt die dat team van 4 scripters leidt, gaat hij dat echt niet goed vinden. Ik werk nu 3 maanden als webmaster/developer, en ik neem de technische beslissingen zeg maar (ook voor anderen aangezien ik de verantwoordelijke ben voor de site). Ook mijn 'kudde' () is (nog) niet overtuigd van het modulen principe. Ik zit hier dagelijks de bugs, 0,0 gedocumenteerde code, fouten in de database, rare akties op de server en nog VEEL MEER van dat soort meuk te fixen . Ik wordt er aardig gestressed van, maar damn...je moet ze in de hand houden . De man die die huidige crap heeft gemaakt is nogal linux freak (heeft ie ook op zijn laptop zitten), en die heeft er een handje van er een guerillia-style op na te houden: andersom CVS'en, scripts blijven kopieren en kopieren ipv aanpassen, overal in de code linux spammen/grapjas maken (echt ).

Het is verschrikkelijk moeilijk om met zulke mensen te werken .

Wat ik nu doe, is alle code die ik zelf herschrijf netjes wegbergen in een mapje 'libraries', en die moet iedereen gebruiken vanaf nu. Desnoods chmod ik hem wel zodat ze eraf blijven .

[TheDane]

Bobco schreef op 23 januari 2003 @ 09:02:
[...]


Is je baas daar ook blij mee? Het lijkt me dat je op die manier nogal wat werk dubbel doet, zonder dat het grote voordelen oplevert. Ik weet ook wel dat codestyles behoorlijk van elkaar kunnen verschillen, maar op het moment dat je zelfs de uitvoer van een ander niet vertrouwt en dat zelf nog een keer bouwt lijkt het me lastig om in een team te werken. Hoe doe jij dat als je echt met 10 man iets moet bouwen?

Over 't algemeen doen we nogal wat werk dubbel inderdaad. Is ook over 't algemeen niks aan te doen, omdat 't over 't algemeen niet generiek is wat we maken. Database layout is steeds anders, dus -om maar iets te noemen- moeten sowieso alle database queries iedere keer herschreven worden. De klant stelt steeds andere eisen aan de visualisatie, dus ook de presentatielaag (templates / template engine) moet regelmatig verbouwd of herschreven worden.

We hebben wel eens geprobeerd om een generieke applicatie te schrijven, maar in de praktijk werkt dit niet echt zoals we hadden gehoopt. Over't algemeen wordt er dus -niet alleen door mij- veel herschreven.

we zitten hier trouwens maar met 4 techneuten .. en als we een gezamenlijk project hebben, dan bouwt iedereen z'n eigen modules, die doorgaans dmv linkjes geintegreerd worden.

[ Voor 9% gewijzigd door TheDane op 23-01-2003 09:38 ]

[TheDane]

Config schreef op 23 January 2003 @ 09:26:

[..]

Wat ik nu doe, is alle code die ik zelf herschrijf netjes wegbergen in een mapje 'libraries', en die moet iedereen gebruiken vanaf nu. Desnoods chmod ik hem wel zodat ze eraf blijven .

chmodden heeft bij ons vrij weinig nut , iedereen zit in wheel

[Verwijderd]

Overdracht van software is ontzettend lastig. Door managers wordt vaak volledig onderschat hoeveel kennis er in de hoofden van de ontwikkelaars zit, maar nergens (duidelijk) op papier staat. Zorg dat management gewust is van de risico's, doe dus een stukje 'verwachtingsmanagement': "Ook al besteden we 2 weken aan overdracht, dan nog is de kans dat er veel fout gaat groot. Daarom moeten we voorzichtig manouvreren na de overdracht, totdat duidelijk is dat alles onder controle is."

Software overdracht checklist (uit de losse pols):
1) Alle source code, zowel de nieuwste als oudere versies (minimaal de aan de klanten uitgeleverde versies)
2) Een lijst van alle source code files, met een globale beschrijving van de functionaliteit per file
3) Een globale omschrijving van het doel, de werking en architectuur van de software
4) Technische documentatie van de software (architectuur, fysiek datamodel, class diagrammen, etc)
5) Lijst met omschrijving uitgeleverde software (welke klanten draaien welke versie op wat voor soort systeem, incl. specifieke configuratie settings, system accounts, etc)
6) Configuratie management document: een gedetailleerde omschrijving van het opzetten van een volledig systeem, inclusief alle benodigdheden (hardware, os, anvullende software), volgorde van handelingen, lijst met alle mogelijke configuratie settings van software met toelichting
7) Relevante voorbeelddata voor het systeem om mee te werken
Testplan om een nieuwe of gewijzigde installatie te valideren voor gebruik

Vervolgens moet je deze lijsten doorlopen om te zien of ze compleet zijn. Loop tijdens de overdracht alle documenten door, zet een volledig schone ontwikkelomgeving op aan de hand van het configuratie management document, test het aan de hand van het test plan, etc.

HTH