Het minpunt van het werk in de softwareontwikkeling.

[MasterTweaker]

Ik ben van mening dat het grootste nadeel van het werk in de softwareontwikkeling is is dat het werk niet echt veel voldoening geeft. Het is meestal zo dat ICT systemen zich voortdurend op de grenzen begeven van wat mogelijk is qua techniek en functionaliteit en hierdoor dus voortdurend veranderd worden en complexer worden. Dit heeft tot gevolg dat de ontwikkelaars voortdurend werken aan een product dat nooit echt af is en qua complexheid meestal de grens opzoekt van wat het menselijk intellect aan kan. Hierdoor is er eigenlijk nooit echt sprake van voldoening bij de ontwikkelaars omdat het systeem eigenlijk altijd verbeterd kan worden en nooit echt af is, en is het ook best stressvol werk. Daarnaast is het werk ook extreem resultaatgericht en de weg naar het resultaat toe vrij chaotisch.

Neem nou als voorbeeld een architect die een gebouw ontwerpt. Als het gebouw er staat dan is het gebouw af en is de architect tevreden met zijn werk. Als een softwarearchitect echter een complex systeem ontwerpt, en er komt een release-versie uit, dan geeft dat uiteraard voldoening, maar dan druppelen vervolgens al snel de bugs binnen van allerhande gebruikers en verouderd het systeem alweer razendsnel qua techniek en functionaliteiten. Het systeem dient dus voortdurend aangepast te worden en is nooit echt af. En op den duur is de documentatie niet meer "up to date", omdat er geen tijd is om dit te onderhouden, en weet niemand meer precies hoe het systeem precies in elkaar zit. De voldoeningsfactor van professionele softwareontwikkeling ligt dus aanzienlijk lager dan in andere sectoren heb ik het idee.

Ik heb het dan trouwens wel over professionele softwareontwikkeling bij een groot softwareproject en niet een klein project waar een paar man aan werken (dit geeft dan wel weer meer voldoening lijkt mij ). Zijn jullie het hier mee eens?

[JBrennan]

Nee, totaal niet eigenlijk.

Ik zou behoorlijk minder voldoening uit mijn werk halen als een applicatie af is en er niets meer aan veranderd. Het is juist leuk als een bestaand systeem verbeterd kan worden. Het kan immers altijd beter/sneller/mooier/efficienter .

Daarnaast is een gebouw ook nooit af. Ja, de rol van de architect kan af zijn. Maar het gebouw krijgt een andere bestemming of krijgt een andere inrichting.

Verandering is een deel van onze maatschappij, of dat nu software of een gebouw is.

[Navi]

Het gras is ergens anders altijd groener

Gebouwen hebben als ze net af zijn ook "bugs", constructiefouten, verkeerde interpretaties van de bouwtekeningen, etc etc
Gebouwen verouderen ook, en de architect is heus niet altijd tevreden

[DrivinUCrazy]

Is het probleem van TS niet voor een deel dat software niet echt tastbaar is?

Je kunt het besturingssysteem voor een industriële machine programmeren; daar zie je heel veel bewegen, herrie maken, knipperen, noem maar op. Het besturingssysteem van een kerncentrale is nog wat wat complexer, maar daar zie je he-le-maal nks aan. Tenminste, dat hoop ik.

Wat ik bedoel is dat je bij software minder snel een tastbaar resultaat ziet. Het kán wel (zie voorbeeld hierboven), maar dat is alleen in heel specifieke branches en bij goed gestructureerde bedrijven zo.

[ Voor 22% gewijzigd door DrivinUCrazy op 16-10-2012 09:39 ]

[CodeCaster]

Hierdoor is er eigenlijk nooit echt sprake van voldoening bij de ontwikkelaars omdat het systeem eigenlijk altijd verbeterd kan worden en nooit echt af is

Vaker releasen waardoor je vaker het genoegen hebt een deel "af" te mogen noemen en waarop je feedback kunt krijgen.

Je moet er inderdaad mee leren leven dat je het vaak alleen hoort wanneer het niet werkt. IT is een ondersteunende functie; men verwácht dat het werkt.

[Evilbee]

DrivinUCrazy schreef op dinsdag 16 oktober 2012 @ 09:38:
Je kunt het besturingssysteem voor een industriële machine programmeren; daar zie je heel veel bewegen, herrie maken, knipperen, noem maar op.

En dat is dus werk dat ik doe En daar haal ik zeker voldoening uit dat door het werk dat ik doe een productie lijn 100% (ja, echt) efficiënter kan draaien.

[Lethalis]

Ach, als software een bug heeft, dan kun je dat fixen en een nieuwe versie klaarzetten.

Als het ontwerp van jouw gebouw een bug heeft, dan stromen de schadeclaims binnen.

Ook niet leuk. Maar ja, je werkt voor het geld.. niet omdat het zo leuk is.

Ik werkte vroeger als technisch CAD tekenaar en dan hoor je verhalen die vele malen erger zijn dan wat je in de ICT meemaakt.

Bijvoorbeeld dat er bespaard is op de dikte van staaldraad en vervolgens een deur van een fabriekshal op iemand terecht is gekomen. En dan begint de lol hoor. De opdrachtgever geeft de schuld aan het ingenieursbureau, het ingenieursbureau leverde weliswaar de tekeningen, maar gaf al aan dat de draad aan de dunne kant was.. maar ja, de opdrachtgever wou het graag zo.. alles moest zo goedkoop mogelijk. Kastje en muur, en in de tussentijd is er een begrafenis.

Of dat alle tekeningen in spiegelbeeld zijn, omdat iemand op een onlogische manier heeft ingemeten. Gevolg: panelen ten waarde van een half miljoen euro zijn geproduceerd en klaar voor de afvalverwerking. Wie gaat dat betalen? Oei oei oei.

Nee, laat mij maar aan wat software prutsen

Ergste fout die ik ooit in mijn werk als CAD tekenaar gemaakt heb: twee getalletjes omgedraaid op een materialenlijst. In plaats van 310 stond er 130 ofzo. Beetje jammer dat de plaat iets van 50x werd uitgevoerd, ergens in China werd geproduceerd, naar Rusland werd vervoerd en vervolgens daar bleek dat de boel niet paste.

Dat was ook een behoorlijke kostenpost. Alleen maar omdat je ergens niet goed opgelet hebt of iets verkeerd las.

Ik werk nu bijna 10 jaar in de ICT als programmeur en de ergste blunder die ik daarin gemaakt heb, kostte 20.000 euro. Ook niet echt grappig, maar het is mij maar 1 keer in de 10 jaar overkomen.. en het was ook echt zoiets stoms als instellingen van het verkeerde sheetje overnemen.

Het maakt niet uit hoe erg ik mijn best doe.. ik blijf af en toe een beetje slordig

Als ik tegenwoordig aan applicaties werk die met getallen te maken hebben (financieel), laat ik ook altijd een collega ernaar kijken op het eind Just to be safe

[ Voor 92% gewijzigd door Lethalis op 16-10-2012 10:36 ]

[robertpNL]

@TS nee totaal niet.

Er komt een fase dat het doel voor de software ontwikkelaar is bereikt (applicatie of proces werkt volgens verwachting of FO) en dan is het klaar. En begin je met een nieuw project.

Uiteraard kan nog achteraf aan een bestaande oplossing worden doorgewerkt (de bugs die op korte of lange termijn zijn ontdekt moeten eruit of functionele wijzigingen die in de praktijk worden ondervonden) maar dat is een continue proces (afhankelijk van het project uiteraard).

En ook als software ontwikkelaar kan je binnen een project altijd twijfelen of je codeert op de juiste manier. Maar dat bereik je alleen met goede leermethode en (zelf)studies.

[Koenvh]

Als er fouten in gebouwen zitten (Bakje van de glazenwasser oid ), dan kost het gelijk miljoenen. In software is dat een stuk minder, dus laat mij maar lekker met software prutsen

[Xyphoid]

Koenvh schreef op dinsdag 16 oktober 2012 @ 10:33:
Als er fouten in gebouwen zitten (Bakje van de glazenwasser oid ), dan kost het gelijk miljoenen. In software is dat een stuk minder, dus laat mij maar lekker met software prutsen

Hangt er van af wat voor software je maakt.
Als je een fout maakt in het besturingssysteem van de kerncentrale van DrivinUCrazy hierboven, kan dat aardig in de kosten gaan lopen...

[Verwijderd]

Lethalis schreef op dinsdag 16 oktober 2012 @ 10:16:
Ach, als software een bug heeft, dan kun je dat fixen en een nieuwe versie klaarzetten.

Als het ontwerp van jouw gebouw een bug heeft, dan stromen de schadeclaims binnen.

Als ik een lelijke bug in m'n software maak (die ook nog eens door 2 testomgevingen heen komt) kan de fabriek duizenden liters melk weggooien, reken maar dat er dan claims komen

Dat maakt 't wel weer interessant, grote kans dat de melk in je koelkast mede mogelijk is gemaakt door de machines waar ik aan werk.

Zoals al gezegd, als je tastbaar resultaat wil zien is het programmeren van machines interessant.

[JBrennan]

Verwijderd schreef op dinsdag 16 oktober 2012 @ 20:36:
[...]


Als ik een lelijke bug in m'n software maak (die ook nog eens door 2 testomgevingen heen komt) kan de fabriek duizenden liters melk weggooien, reken maar dat er dan claims komen

Dat maakt 't wel weer interessant, grote kans dat de melk in je koelkast mede mogelijk is gemaakt door de machines waar ik aan werk.

Zoals al gezegd, als je tastbaar resultaat wil zien is het programmeren van machines interessant.

Bugs in facturatie applicaties vinden klanten ook niet fijn. Vooral als ze nadelig zijn .

[Lethalis]

JBrennan schreef op woensdag 17 oktober 2012 @ 10:08:
[...]

Bugs in facturatie applicaties vinden klanten ook niet fijn. Vooral als ze nadelig zijn .

Precies

Of als omzetcijfers niet kloppen in de statistiek enzo. Daar zijn ze ook dol op

*rent snel weg en verbergt zich achter een kast*

[Testert]

Tja, zo ben ik eens betrokken geweest bij een foutje in een batchprogramma, waardoor de batch niet alleen ver buiten het batchwindow bleef draaien, maar alle resources opvrat. Zo lag gelijk alle administratieve productie plat en kon de telefooncentrale de klanten nauwelijks informeren.

Ik ben betrokken geweest bij een project nav de Wabeke affaire, om klanten tegemoet te komen. Dat is niet zo bevredigend. Projecten waarvan je vooraf al weet dat duizenden klanten blij zullen zijn met de overzichten of nieuwe services zijn daarentegen wèl weer heel leuk.

[Quinz]

Ik denk dat het grootste minpunt de snelle (r)evolutie is van mogelijkheden. Je hoeft maar even te knipperen met je ogen en je wordt voorbijgestreefd. Hierdoor ben je continu bezig nieuwe technieken te leren. Natuurlijk is dat leuk, maar het is lastig je te focussen op één specifiek onderdeel. En op een dag vind je het wel prima.

Een voorbeeld:
In den beginne werd er veel geprogrammeert met talen als C, Pascal en Cobol, op mainframe platformen, etc. Volksstammen zeer gekwalificeerde mensen hebben zich de materie eigen gemaakt. De techniek stond echter niet stil en al gauw waren er (betere) alternatieven. Als je niet continu investeert loop je alweer twee stappen achter. Veel van de gekwalificeerde mensen konden of wilden zich niet storten op nieuwe technieken. Gevolg een CV die niet meer aansluit bij de vraag.

Ga maar na het zijn met name specifike generaties die technieken beheersen. Een PHP-er van 50+ kom je amper tegen. Net zoals je een Cobolprogrammeur van 20 ook niet tegenkomt.

Als je dit vergelijkt met andere beroepen (leraar, advocaat of arts) gaan de ontwikkelingen lang niet zo snel.

[Basti504]

Je zou inderdaad eens kunnen kijken naar de industriele automatisering, het programmeren van machine lijnen en dergelijke. Momenteel ben ik gedetacheerd bij een machine fabriek en werk aan een complete machine lijn en transport systeem voor diervoeding (die in de supermarkt komen). Wanneer zoiets afgewerkt is en autonoom draait geeft dat wel een flinke voldoening.

Het werk is ook uitdagend omdat je niet alleen met software te maken hebt, maar ook met hardware, mechanische en elektrische problemen.