Slecht gesteld met programmeervaardigheden

Even iemand ingehuurd gehad van een uitzendbureau?
Personeel wordt weining gewaardeerd.
Bij een klant stonden een stuk of twintig puntlasmachines en die werden niet meer ingesteld en er gingen dingen mis en niemand wist wie die machines altijd instelde en de fabrikant moest komen om les te geven.

Lijkt me geen gebrek aan programmeervaardigheden, dit is een gebrek aan documentatie!

De documentatie is inderdaad heel belangrijk. Maar de kundigheid tegenwoordig laat ook te wensen over, maar het valt ook niet mee om goede mensen te krijgen en te houden. Zeker nu het weer aardig begint aan te trekken, de mensen stappen weer sneller over. En als er dan net een project gereed is en slecht gedocumenteerd, heb je wel een probleem als die persoon vertrekt.

Heel veel kennis zit momenteel ook buiten het bedrijf. Een consultant voor project x, een andere voor project y en ze zijn weg.

Op 6 april 2018 15:49:11 schreef Djenn:
Lijkt me geen gebrek aan programmeervaardigheden, dit is een gebrek aan documentatie!

Het is een geval van beide. Als software developer hamer ik er zelf altijd op dat code zodanig geschreven en gestructureerd moet zijn dat commentaar in principe overbodig is. Veel te vaak kom ik code tegen waarin de commentaar in spreektaal uitlegt wat de code doet, maar niet waarom. In 99% van de gevallen wil je net de gedachtengang van de originele developer weten, namelijk waarom er net voor die methode van werken gekozen werd.

De stelregel is nochtans eenvoudig (uit Code Complete):

• Code moet zeggen WAT een systeem moet doen en HOE.
• (Eventuele) commentaar dient om uit te leggen WAAROM: bijvoorbeeld waarom een developer deze oplossing koos ipv een veel gangbare oplossing.
• Documentatie moet een overzicht bieden over het geheel en moet eerder toegankelijk zijn voor maintenance en gebruikers.

Helaas kosten goede code en documentatie tijd, maar dat laatste is een vloekwoord bij management

en dat niemand op dit moment eigenlijk nog snapt wat er precies in de code staat

Arco, één ding moet je ze nageven: eerlijk zijn ze wel

Op 6 april 2018 16:05:20 schreef Lambiek:
En als er dan net een project gereed is en slecht gedocumenteerd, heb je wel een probleem als die persoon vertrekt.

Kleine anekdote: ik heb ooit een project geweten waarvan de developer weigerde zijn code te documenteren. Omdat hij de enige was die zowel het systeem als de software kende, durfde men hem niet vervangen. Ze hebben iemand extra aangenomen die de taak kreeg zijn code te documenteren, om hem alsnog te kunnen ontslaan. Gevolg: twee developers met een job-4-life

Marlon

Het is niet een probleem van tegenwoordig en niet specifiek van software. Het ligt veel meer aan een slecht functionerende organisatie en gebrek aan leidinggeven. Als niet iedereen voortdurend wordt gewezen op het belang van up-to-date documentatie en daarop ook wordt gecontroleerd hoef je maar te wachten op de chaos.

Een voorbeeld uit de héél oude doos:
In 1965 werd een nieuwe brandweerkazerne gebouwd, met -voor die tijd- een uitgebreide zwakstroominstallatie.
Vanuit de "seinzaal" zoals dat toen werd genoemd, tegenwoordig heet dat meldkamer, konden de kantelpoorten elektrisch worden geopend, alarmering van het personeel met gekleurde lichtsignalen zodat men wist welke voertuigen moesten uitrukken als het gesproken woord uit de omroepinstallatie was gemist, intercomverbinding met politie en ambulancedienst, controle van diverse installaties, enz.

Een jaar of 5 later traden de eerste problemen op; kantelpoorten gingen niet meer open, lichtsignalen die af en weigerden, intercom die niet werkte, verlichting die uitviel, enz.
De chef-monteur die de leiding had gehad bij de installatie was door zijn werkgever van het installatiebureau ontslagen en het installatiebureau had verzuimd de vele wijzigingen in de oorspronkelijke tekeningen en schema's op te nemen. De documentatie was minder waard dan het papier waarop het was gedrukt.

Omdat het elektrotechnisch installatiebureau er ook niet meer uitkwam zette de brandweer een paar brandwachten met een elektrotechnische opleiding in om de installatie in kaart te brengen en te onderhouden.

Op 6 april 2018 16:53:06 schreef Marlon:
Kleine anekdote: ik heb ooit een project geweten waarvan de developer weigerde zijn code te documenteren. Omdat hij de enige was die zowel het systeem als de software kende, durfde men hem niet vervangen. Ze hebben iemand extra aangenomen die de taak kreeg zijn code te documenteren, om hem alsnog te kunnen ontslaan. Gevolg: twee developers met een job-4-life

Dat is toch te gek voor woorden, op deze manier heb je als werkgever niets meer te zeggen.

Maar inderdaad het gebeurt wel.

... dan lijkt het mij dat de managers nog onbekwamer zijn dan de programmeurs. Als je een externe partij inhuurt voor een klus zonder zelfs nog maar vast te leggen wat ze allemaal gaan opleveren (men spreekt dan van "deliverables" in het Nieuw-Nederlands) wat is dan je meerwaarde?

In dit geval geloof ik dat eea het gevolg is van het feit dat KPN iTV gebruik maakt van Silverlight.

Dat was indertijd vast de snelste en goedkoopste manier om iTV te maken. Tenminste, dat zei Microsoft. Maar ja, dan ben je natuurlijk wel afhankelijk van ondersteuning in de browser. En die heeft Firefox niet meer voor Silverlight.

Ik kan me voorstellen dat best wel wat code moet worden veranderd om die afhankelijkheid kwijt te raken. Dat wordt programmeren. Misschien is Adobe Flash een goed idee? Of ze lenen wat code van dochter XS4ALL. Want WebTV doet het prima in Firefox.

En over dat documenteren van code, dat is niet heel eenvoudig. Alhoewel mijn code ruim van commentaar wordt voorzien heb ik af en toe geen idee wat ik toen bedoelde als ik weer eens kijk naar een oud programma.

Documenteren is niet hetzelfde als commentaar schrijven. Als je code iet of wat netjes geschreven is dan is er niet veel commentaar nodig, idealiter zelfs helemaal geen.

Belangrijk is dat de code wordt opgedeeld in blokjes met elks een welbepaalde functie of doel, en nauwkeurig vastgelegde invoer en uitvoer.

De documentatie omvat dan een overzicht van de blokjes en hun interactie.

Ooit ergens gelezen op het WWW, uit het "Real Programmers Handbook":

Real programmers don't write documentation.
If it was hard to write, it should be hard to read.

Groetjes,
eSe

Probleem is dat in het huidige economische systeem werkgevers worden aangemoedigd om eigen mensen te ontslaan en vervolgens externe partijen voor hetzelfde werk in te huren... Iedere paar jaar zit er een nieuw clubje, en de ene club leert niets van de andere.

Op 6 april 2018 19:07:36 schreef Ledlover:
Iedere paar jaar zit er een nieuw clubje, en de ene club leert niets van de andere.

Mijn observatie is een andere.
Die clubjes externen houden elkaar aan het werk. De eerste club maakt er een zootje van, dat de volgende club /zou/ moeten opruimen.
Daarbij creëert club 2 zoveel rotzooi dat club 3 wordt ingehuurd om DIE troep weer recht te zetten.
Daarna denkt het management *) dat clubje 1 toch niet zo heel slecht was en huurt club 1 weer in.
En de cirkel begint opnieuw.

Het old-boys-network houdt zichzelf zo mooi aan het werk.

*) Het kostte heel veel moeite om dit woord uit mijn ramplank te krijgen

Kei interessant allemaal, maar helaas heeft 't niks met elektronica te maken.