Ervaringen met outsourcing

[HawVer]

Sinds een tijdje werken we hier met een Roemeens team die hier in Nederland een tijdje gewerkt heeft en nu vanuit Roemenie werken. Maar wat is dat een verschrikkelijk ramp. De applicatie is een n tier applicatie waarvan alleen de client exe tijdens het starten al 200 mb geheugen gebruik heeft! Tijdens het starten probeert de client ene user ini in te lezen en slaat finaal vast, oftewel de exceptie wordt totaal niet opgevangen.

Nadat we dat probleem opgelost hadden konden we inloggen op de applicatie. Het verzenden van data is verschrikkelijk traag en dat terwijl er maar één client verbinding heeft en de server applicatie op dezelfde pc draait. Dat probleem hebben we onderzocht met een profilter. Het bleek dat het grootste probleem zat in het xml inlezen en schrijven wat vrij intensief gedaan werd.

We hebben daarna de broncode bekeken en dat was al niet veel beter. Er zit geen enkele vorm van transactie afhandeling in. De client laadt tijdens het starten een bak met data in en tijdens de hele sessie wordt die bak als uitgangspunt gebruikt, Bij het opslaan worden de gewijzigd gegevens naar de server verzonden en daar verwerkt. Client nummer 2 zit dan dus met verouderde gegevens. Geen refresh van data mogelijkheid of 'what so ever'.
In code zat enorm veel hergebruikt, het betere knip en plak werk.

Het huilen stond me nader dan het lachen. Zijn er hier meer mensen die goede/slechte ervaring hebben met outsourcing?

[Boss]

Lijkt me niet zozeer een probleem dat te maken heeft met outsourcing, als wel met gewoon een slecht team. Dat had je ook in NL kunnen treffen.

En, nofi, maar misschien is de aansturing / begeleiding niet optimaal geweest? Volgens mij werkt outsourcing alleen als je hele goede specs geeft aan de uitvoerders.

[HawVer]

Boss schreef op woensdag 19 december 2007 @ 11:05:
En, nofi, maar misschien is de aansturing / begeleiding niet optimaal geweest? Volgens mij werkt outsourcing alleen als je hele goede specs geeft aan de uitvoerders.

Op zichzelf een logische vraag. In ieder geval op functioneel vlak hebben we tot op de knoppen en tekst nauwkeurig een omschrijving gegeven, use cases erbij, een volledig datamodel. Het enige waar ze zich druk om moesten maken is datgene wat tussen omschrijving en datamodel zat namelijk de technische kant. Met een team van 2 seniors en 3 junior ontwikkelaars mag je verwachten dat ze op technisch vlak enigszins een invulling daaraan kunnen geven. Is dat teveel gevraagd van een ontwikkelaar? Persoonlijk zou ik daar zelf prima mee uit te voeten kunnen.

[Janoz]

Als ik dat zo lees dan is er ook wel iets mis met de specs en de QA. Als je het mij eerlijk vraagt zijn dit typische dingen die al veel eerder in het traject naar voren hadden kunnen komen.

---edit
Ah, al iets meer info ...

Maar dan nog, opstarttijd en afhandeling van concurrency zijn typisch dingen die ook in een functionele specificatie terug zouden moeten komen.

[ Voor 33% gewijzigd door Janoz op 19-12-2007 11:19 ]

[HawVer]

Janoz schreef op woensdag 19 december 2007 @ 11:16:
Als ik dat zo lees dan is er ook wel iets mis met de specs en de QA. Als je het mij eerlijk vraagt zijn dit typische dingen die al veel eerder in het traject naar voren hadden kunnen komen.

---edit
Ah, al iets meer info ...

Maar dan nog, opstarttijd en afhandeling van concurrency zijn typisch dingen die ook in een functionele specificatie terug zouden moeten komen.

Dat concurrency in je functionele specificaties terugkomt is logisch, dat wordt min of meer aangestuurd vanuit je bussinesslogic. De opstarttijd van je applicatie vind ik persoonlijk de verantwoordelijkheid van de ontwikkelaar. Een klant wil altijd een applicatie hebben die snel opstart.
Maar dan blijven er nog wel een heel aantal dingen liggen die gewoon slecht zijn gebouwd. 200mb geheugen gebruik is absoluut niet nodig voor een relatief kleine applicatie. Een aantal van die zaken moet je als ontwikkelaar, en zeker als senior toch wel op kunnen pakken.

[Boss]

Wat geven ze zelf als reden / excuus?

Misschien hebben de seniors de juniors een beetje te veel hun gang laten gaan...

[MAX3400]

Bij een tekort aan programmeer-kennis, zou ik inderdaad zonder meer van je aannemen dat 200MB wat overdreven is. Maar je geeft niet aan wat de overige randvoorwaarden zijn.

Ik zit zelf in de outsourcing (zijnde systeembeheerder) en als je ziet wat voor applicaties soms gewenst/geeist worden op bepaalde omgevingen, dan kan ik ook niet anders doen dan de klant inlichten dat het misschien niet een briljant idee is. Maar vaak wordt het wel geinstalleerd met alle desastreuze gevolgen van dien.

200MB? Tja, eerlijk gezegd vraag ik me af waar je je druk over maakt; een bankje van 512MB RAM kost tegenwoordig niet meer dan een flinke lunch. Aan de andere kant komt het op me over dat als je de tijd had gehad, dat je het beter had kunnen doen. Kan dus niet echt je vraagstelling en je probleem relateren en beantwoorden.

[ Voor 4% gewijzigd door MAX3400 op 19-12-2007 12:28 ]

[HawVer]

MAX3400 schreef op woensdag 19 december 2007 @ 12:28:
Bij een tekort aan programmeer-kennis, zou ik inderdaad zonder meer van je aannemen dat 200MB wat overdreven is. Maar je geeft niet aan wat de overige randvoorwaarden zijn.

Ik zit zelf in de outsourcing (zijnde systeembeheerder) en als je ziet wat voor applicaties soms gewenst/geeist worden op bepaalde omgevingen, dan kan ik ook niet anders doen dan de klant inlichten dat het misschien niet een briljant idee is. Maar vaak wordt het wel geinstalleerd met alle desastreuze gevolgen van dien.

200MB? Tja, eerlijk gezegd vraag ik me af waar je je druk over maakt; een bankje van 512MB RAM kost tegenwoordig niet meer dan een flinke lunch. Aan de andere kant komt het op me over dat als je de tijd had gehad, dat je het beter had kunnen doen. Kan dus niet echt je vraagstelling en je probleem relateren en beantwoorden.

Wel als je bedenkt dat ze nu ongeveer op 10% van de functionaliteit zitten.

[MAX3400]

HawVer schreef op woensdag 19 december 2007 @ 13:01:
[...]

Wel als je bedenkt dat ze nu ongeveer op 10% van de functionaliteit zitten.

Vervelend maar dat lees ik nu voor het eerst. Bijkomend nadeel is dat je een x tier programma in gebruik hebt genomen waarvan ik niet kan beoordelen welke tier hoeveel % van de I/O of transacties of whatever voor zijn rekening neemt.

Kan me goed voorstellen dat hier misschien later ook een schoen gaat wringen.

[MisterBlue]

HawVer schreef op woensdag 19 december 2007 @ 10:56:

Het huilen stond me nader dan het lachen. Zijn er hier meer mensen die goede/slechte ervaring hebben met outsourcing?

Zoek je naar ervaringen met outsourcing in het algemeen (dus ook met een vertrouwde Nederlandse IT onderneming) of specifiek outsourcing/offshoring naar het buitenland.

Ik zie niet direkt een relatie tussen de geschetste problemen en het wel of niet outsourcen. Deze problemen kunnen zich ook voordoen als je de applicatie laaat bouwen door de interne IT afdeling.

[Verwijderd]

HawVer schreef op woensdag 19 december 2007 @ 11:15:
[...]

...knip...

Met een team van 2 seniors en 3 junior ontwikkelaars mag je verwachten dat ze op technisch vlak enigszins een invulling daaraan kunnen geven. Is dat teveel gevraagd van een ontwikkelaar? Persoonlijk zou ik daar zelf prima mee uit te voeten kunnen.

HawVer, ben je niet bekend met het feit dat in veel organisaties mensen vanzelf senior worden als ze een aantal jaar werkervaring hebben? Je kan jezelf noemen wat je wil, dat is geen garantie voor kwaliteit. Misschien een rare vraag, maar hebben jullie niet van SVN gehoord? Als je een fatsoenlijke SVN server zou hebben gehad, waarbij het team regelmatig gecommit zou hebben, dan had je de hand er beter op kunnen leggen.
Vooral als je werkt met een team waarmee je nog weinig ervaring hebt. Dit heeft niets met outsourcen te maken, maar met de blunders die in Nederland gemaakt zijn. Als je een tuin laat aanleggen dan geef je toch ook niet een paar tekeningen aan de hovenier en zeg je: zoek 't maar uit? Dan blijf je er toch ook bij om dingen bij te kunnen stellen. Blijkbaar hebben jullie geen ervaring met werken op afstand, waardoor je nu te laat achter deze problemen gekomen bent. Stroomlijn het proces van software ontwikkeling waarbij je ten minste met SVN werkt en ook van toeleveranciers eist dat ze hun code committen op jullie SVN server. Dan was je na de eerste commit er al achter gekomen dat ze dikke poep opleverden, en zou het nu niet dikke boehoe richting de outsource markt zijn.

[.oisyn]

Dat heet source control, SVN is daar een implementatie van

Hier even de andere kant van het verhaal: wij zijn namelijk zelf de "outsourcees", met de outsourcers in California, US. Wij staan niet bepaald te boek als het afleveren van prutswerk; wat nou precies het verschil is met het Roemeense bedrijf kan ik niet echt zeggen (omdat ik dat bedrijf verder niet ken natuurlijk). Wel werkt hier getalenteerd personeel, is er een goede leiding en hebben we tevens een paar keer per week videoconferences met onze Amerikaanse collega's. Ook meeten we eens in de paar maanden in real life - de ene keer gaan een paar van ons die kant op, de andere keer andersom (de afgelopen week waren zij hier). Ik vind dat wel fijn - je kunt een gezicht en een karakter aan een e-mailadres koppelen, en dat bevordert de algemene communicatie enorm.

Wat misschien wel een groot verschil is is dat wij actief meedenken in de richting die opgegaan moet worden en erg nauw samenwerken met de teams daar. We krijgen bijvoorbeeld geen design aangeleverd om dat vervolgens maar naar eigen goeddunken te implementeren. We bepalen het design samen met hen, waarbij zij aangeven wat ze graag zouden zien en wij suggereren hoe dat het beste bereikt kan worden. Maar goed, misschien is dat ook wel inherent aan het feit dat wij technologie maken voor games, en geen n-tier business applicaties.

[ Voor 102% gewijzigd door .oisyn op 19-12-2007 19:06 ]

[HawVer]

MisterBlue schreef op woensdag 19 december 2007 @ 14:42:
[...]


Zoek je naar ervaringen met outsourcing in het algemeen (dus ook met een vertrouwde Nederlandse IT onderneming) of specifiek outsourcing/offshoring naar het buitenland.

Ik zie niet direkt een relatie tussen de geschetste problemen en het wel of niet outsourcen. Deze problemen kunnen zich ook voordoen als je de applicatie laaat bouwen door de interne IT afdeling.

Ik zoek eigenlijk naar meer ervaringen op het gebied van outsourcing. Het gaat me niet specifiek om het probleem dat ik beschreven heb. Dat was meer om mijn ervaringen te onderstrepen. maar het gaat over het algemeen. Wat zijn good practices en bad practices. Wat voor ervaringen hebben andere mensen met outsourcing, positief dan wel negatief?

Verwijderd schreef op woensdag 19 december 2007 @ 17:45:
[...]
HawVer, ben je niet bekend met het feit dat in veel organisaties mensen vanzelf senior worden als ze een aantal jaar werkervaring hebben? Je kan jezelf noemen wat je wil, dat is geen garantie voor kwaliteit.

Daar ben ik inderdaad al achter. Ik heb ook gemerkt dat het een enorm verschil is in welk land het uitgevoerd wordt.

Misschien een rare vraag, maar hebben jullie niet van SVN gehoord? Als je een fatsoenlijke SVN server zou hebben gehad, waarbij het team regelmatig gecommit zou hebben, dan had je de hand er beter op kunnen leggen.

Ze werken via vpn op sourcesafe. De versie controlle is niet zo zeer het probleem.

Vooral als je werkt met een team waarmee je nog weinig ervaring hebt. Dit heeft niets met outsourcen te maken, maar met de blunders die in Nederland gemaakt zijn. Als je een tuin laat aanleggen dan geef je toch ook niet een paar tekeningen aan de hovenier en zeg je: zoek 't maar uit? Dan blijf je er toch ook bij om dingen bij te kunnen stellen. Blijkbaar hebben jullie geen ervaring met werken op afstand, waardoor je nu te laat achter deze problemen gekomen bent. Stroomlijn het proces van software ontwikkeling waarbij je ten minste met SVN werkt en ook van toeleveranciers eist dat ze hun code committen op jullie SVN server. Dan was je na de eerste commit er al achter gekomen dat ze dikke poep opleverden, en zou het nu niet dikke boehoe richting de outsource markt zijn.

Ik vind dat je nogal kort door de bocht bent. Ten eerste hebben we duidelijke omschrijvingen opgeleverd hoe het er functioneel uit moet zien. Wij zijn niet gespecialiseerd op het gebied van .NET ontwikkeling. Dat is de reden dat we een team vanuit het buitenland hebben gevraagd. Op het gebied van architectuur hebben wij duidelijk aangegeven hoe we het willen. Met andere woorden we hebben de hovenier (dagelijks!) bijgestuurd. Je verwacht niet van een software ontwikkelaar dat je om het uur moet zeggen dat hij de onderkant van zijn schop moet gebruiken in plaats van de steel om een gat te graven.
Ten tweede hebben we ook erg goede ervaringen op het gebied van outsourcing. We hebben een onderdeel van een bestaande applicatie laten ontwikkelen door een (Nederlands) outsource team die uitstekend werk heeft afgeleverd. Een module tegen een bestaande applicatie schrijven lijkt mij complexer dan het schrijven van een nieuwe applicatie (relatief) Dus nee, je hoort me absoluut niet zeggen dat outsource teams alleen maar poep opleveren. Spreekt het je op enig vlak persoonlijk aan? Ervaringen met oursourcing?

[HawVer]

.oisyn schreef op woensdag 19 december 2007 @ 18:45:
Dat heet source control, SVN is daar een implementatie van

Hier even de andere kant van het verhaal: wij zijn namelijk zelf de "outsourcees", met de outsourcers in California, US. Wij staan niet bepaald te boek als het afleveren van prutswerk; wat nou precies het verschil is met het Roemeense bedrijf kan ik niet echt zeggen (omdat ik dat bedrijf verder niet ken natuurlijk). Wel werkt hier getalenteerd personeel, is er een goede leiding en hebben we tevens een paar keer per week videoconferences met onze Amerikaanse collega's. Ook meeten we eens in de paar maanden in real life - de ene keer gaan een paar van ons die kant op, de andere keer andersom (de afgelopen week waren zij hier). Ik vind dat wel fijn - je kunt een gezicht en een karakter aan een e-mailadres koppelen, en dat bevordert de algemene communicatie enorm.

Ja dat is inderdaad enorm belangrijk heb ik wel gemerkt. De laatste maand is er niemand meer geweest en je merkt dat de communicatie via de email een stuk moeilijker gaat, je kan moeilijker overbrengen wat je verwacht en hoe het moet worden. Toch is de laatste maand maar een klein onderdeel van de tijd dat je voor ons gewerkt hebben.

Wat misschien wel een groot verschil is is dat wij actief meedenken in de richting die opgegaan moet worden en erg nauw samenwerken met de teams daar. We krijgen bijvoorbeeld geen design aangeleverd om dat vervolgens maar naar eigen goeddunken te implementeren. We bepalen het design samen met hen, waarbij zij aangeven wat ze graag zouden zien en wij suggereren hoe dat het beste bereikt kan worden. Maar goed, misschien is dat ook wel inherent aan het feit dat wij technologie maken voor games, en geen n-tier business applicaties.

Dat is inderdaad een groot verschil met Nederland. Je moet die mensen tot op de punt en de komma vertellen hoe het moet worden. Er kan absoluut geen onderdeel missen. Als er iets mist verwacht je van een ontwikkelaar dat hij door vraagt hoe het precies moet worden, maar ook dat hij in staat is om zelf mee te denken. Hoe verzorgen jullie de QA?

[Remus]

Ik heb zelf geen ervaring met outsourcing, maar er wordt hier momenteel onderzoek gedaan naar het opzetten van een eigen ontwikkelteam in oost Europa. Een partnerbedrijf dat al de stap heeft gemaakt vertelde onder meer dat het vaak noodzakelijk is om iemand van je eigen bedrijf daar te plaatsen om leiding te geven (als het een eigen team is) of de vinger aan de pols te houden (bij outsourcing), omdat er anders vaak gewoon met de pet naar gegooid wordt en dat er of niks gebeurt of dat er broddelwerk opgeleverd wordt.

[MisterBlue]

Ik zoek eigenlijk naar meer ervaringen op het gebied van outsourcing.

Ok, als subcontractor hebben we weleens programmeer werk gedaan voor een ander bedrijf. Het contact ging voornamelijk via skype, instant messaging en een soort forum. Er werd gebruik gemaakt van de combinatie subversion en trac. Dit is belangrijk, want de klant maakte gebruik van de trac timeline feature om elke commit die we deden nauwkeurig te reviewen. We kregen vaak al dezelfde dag feedback hierop en moesten vaak dingen dan anders doen om aan hun standaarden te voldoen. Dus ondanks dat ze werk hadden geoutsourced, hielden ze wel volledige controle op de kwaliteit.

[Verwijderd]

HawVer schreef op woensdag 19 december 2007 @ 21:27:
[...]

Ik zoek eigenlijk naar meer ervaringen op het gebied van outsourcing. Het gaat me niet specifiek om het probleem dat ik beschreven heb. Dat was meer om mijn ervaringen te onderstrepen. maar het gaat over het algemeen. Wat zijn good practices en bad practices. Wat voor ervaringen hebben andere mensen met outsourcing, positief dan wel negatief?


[...]

Daar ben ik inderdaad al achter. Ik heb ook gemerkt dat het een enorm verschil is in welk land het uitgevoerd wordt.

[...]

Ze werken via vpn op sourcesafe. De versie controlle is niet zo zeer het probleem.

[...]

Ik vind dat je nogal kort door de bocht bent. Ten eerste hebben we duidelijke omschrijvingen opgeleverd hoe het er functioneel uit moet zien. Wij zijn niet gespecialiseerd op het gebied van .NET ontwikkeling. Dat is de reden dat we een team vanuit het buitenland hebben gevraagd. Op het gebied van architectuur hebben wij duidelijk aangegeven hoe we het willen. Met andere woorden we hebben de hovenier (dagelijks!) bijgestuurd. Je verwacht niet van een software ontwikkelaar dat je om het uur moet zeggen dat hij de onderkant van zijn schop moet gebruiken in plaats van de steel om een gat te graven.
Ten tweede hebben we ook erg goede ervaringen op het gebied van outsourcing. We hebben een onderdeel van een bestaande applicatie laten ontwikkelen door een (Nederlands) outsource team die uitstekend werk heeft afgeleverd. Een module tegen een bestaande applicatie schrijven lijkt mij complexer dan het schrijven van een nieuwe applicatie (relatief) Dus nee, je hoort me absoluut niet zeggen dat outsource teams alleen maar poep opleveren. Spreekt het je op enig vlak persoonlijk aan? Ervaringen met oursourcing?

Je schop-steel analogie vond ik erg amusant, maar ik bedoel meer; een keer een kijkje in de tuin nemen kan geen kwaad. Zoals je aangaf, gebruikten jullie wel source control. Dan denk ik; je hoeft niet in .NET gespecialiseerd te zijn om te zien of ze de architectuur zo opzetten zoals jullie gevraagd hadden.

Zelf werk in binnen Nederland met een paar mensen die niet om te hoek wonen. Alle communicatie gaat via mail, skype en af en toe spreken we eens wat af om een uitje te doen. Daarnaast in het verleden een aantal opdrachten met een bedrijf in Sydney gedaan. Belangrijk binnen de Computer Mediated Communication is grounding. Zoals .oisyn als aangaf; je moet gevoel voor elkaar krijgen, en het idee krijgen dat er iemand achter de zwarte lettertjes zit.

Je moet in ieder geval altijd zorgen dat de communicatielijnen open blijven, dat er een aantal keer per week gepraat wordt; hoe gaat het? hoe ver zijn jullie? lopen jullie tegen problemen aan in de omschrijving? Als je na 2 weken nog geen vraag hebt gehad over de specs, dan gaat er bij mij een lampje branden; of je hebt super duper briljante specs schrijvers, of het team gebruikt ze niet helemaal zoals je bedoelde.

Maar nogmaals, dit probleem had net zo goed binnen Nederland kunnen voorkomen. Het is een kwaliteitsprobleem. In ieder geval nooit een ikea bouwpakket over de schutting gooien en dan hopen dat je een stoel terug krijgt. Ik zou even over de schutting kijken. Als advies; stop met de partner en ontbind het contract aangezien ze niet de kwaliteit leveren die je mag verwachten. Beter ten halve gekeerd, dan ten hele gedwaald.

[YopY]

Er zijn een aantal tools op de markt (sowieso voor Java, waarschijnlijk ook wel voor .net) die verschillende aspecten van code kwaliteit kunnen controleren en daar een cijfer aan kunnen koppelen. Ik heb zelf geen ervaring met outsourcing of outsourcery, maar als ik een opdracht aan een extern bedrijf zou geven, dan zou ik in de voorwaarden ook bepaalde minimumwaarden aan de resultaten van dat soort programma's stellen - niet meer dan X stijlfouten, minstens 60/70/80/90% test coverage, en nog een stel andere controles. Naast de functionele eisen ook een lijst maken van onderliggende kwaliteitseisen.

Aan de andere kant van het verhaal zijn de programmeurs zelf. Tenzij ze met de zweep achterna gezeten worden om maar zo snel mogelijk code te kloppen, of tenzij ze eigenlijk niet goed weten waar ze mee bezig zijn, zou iedere weldenkende programmeur wel na kunnen gaan dat een programma dat nog maar 10% af is geen 200 MB gebruiken mag na het opstarten - zelfs als geheugen relatief goedkoop is, is zo'n cijfer redelijk onacceptabel (afhankelijk van het programma). Zelfde met snelheid. Van te voren moet een richtlijn aangegeven worden op wat voor systeem het programma minimaal acceptabel draaien moet. Eventueel kan er door communicatie tussendoor aanpassingen gemaakt worden aan die eisen / wensen (zoals een proper flexibel programma beaamt), zolang die maar acceptabel en goed onderbouwd zijn - niet van ondermaats en belabberd programmeren of slechte ontwerpkeuzes.

[.oisyn]

HawVer schreef op woensdag 19 december 2007 @ 21:33:
Hoe verzorgen jullie de QA?

Dat verschilt. Eigenlijk doen wij twee dingen: tech en conversions. Onder de tech vallen dingen als de 3d engine, de asset manager GUI en allerlei build tools om die assets om te zetten naar data dat door de game interpreteerbaar is. Dat is niet een softwarepakket dat in z'n geheel wordt gemaakt en uiteindelijk wordt afgeleverd - het is al jaren in ontwikkeling en wordt continu aangepast voor nieuwe technologie en feature demands die daaruit voortvloeien. Het QA lijntje, als je het al zo kunt noemen, is nogal kort. Je test zelf wat je maakt, dat check je in, en in de US maken ze elke dag een label op de source control server waar alle content lui (level designers, modelers, etc.) mee werken. De meeste programmeurs daar werken doorgaans direct op de head revision. Als er iets stuk is en dat zit in de recentste label, dan wordt er gewoon teruggesynct en krijgen we een bugreport. Dit uiteraard naast alle geautomatiseerde dingen zoals een standaard code build voor alle platforms en games zodra er nieuwe code wordt ingecheckt, waardoor je een e-mailtje krijgt als jouw code iets op een ander platform breekt oid (wat in eerste instantie natuurlijk al voorkomen moet worden, maar het is een goede failsafe). Unit tests werken doorgaans niet zo, je kan bijvoorbeeld moeilijk nagaan of een bepaalde polygoon wel goed rendert ofzo .

Wat conversions betreft ligt het wat anders, de development daarvan is geheel voor onze rekening, maar daarbij maken we wel gebruik van het QA department van de klant, die een shitload aan gametesters hebben om het spel door te spelen. TCR testing en submission bij MS/Sony/Nintendo verzorgen we verder zelf

[RedBeard]

YopY schreef op donderdag 20 december 2007 @ 11:23:
Er zijn een aantal tools op de markt (sowieso voor Java, waarschijnlijk ook wel voor .net) die verschillende aspecten van code kwaliteit kunnen controleren en daar een cijfer aan kunnen koppelen. Ik heb zelf geen ervaring met outsourcing of outsourcery, maar als ik een opdracht aan een extern bedrijf zou geven, dan zou ik in de voorwaarden ook bepaalde minimumwaarden aan de resultaten van dat soort programma's stellen - niet meer dan X stijlfouten, minstens 60/70/80/90% test coverage, en nog een stel andere controles. Naast de functionele eisen ook een lijst maken van onderliggende kwaliteitseisen.

Ook bij dit soort tooling blijft het een kwestie van controleren.

Ik kan je een applicatie geven met 100% code coverage, welke nog steeds bagger is.
Maar als je de kwaliteit van de testen goed controleert kan dit inderdaad een goed methode zijn. Een optie is dan ook om zelf de test cases op te stellen.