Discussies over softwarearchitectuur in kleine organisatie

[willempipi]

...

[ Voor 101% gewijzigd door willempipi op 24-07-2023 23:12 ]

[Verwijderd]

Is er geen IT manager waar jullie beide onder vallen? Ga daarmee eens praten. Doe bijv een voorstel voor een kwaliteitsanalyse/QA voordat je iets in productie neemt. Ik zie zoiets niet als lullen over je collega's. Je wordt er nu zelf de dupe van, en dat kan niet de bedoeling zijn toch?

Overtuigingskracht zijn imo geen managementskils. Dit heeft te maken met ervaring, en dat komt vanzelf. Je moet natuurlijk wel het woord durven nemen, maar dat is meer persoonlijkheid. Probeer jezelf het doel te stellen dat je elke vergadering x keer je punt wilt maken. Uiteindelijk gaat het vanzelf.

[SaphuA]

.

[ Voor 98% gewijzigd door SaphuA op 31-01-2022 14:52 ]

[willempipi]

.

[ Voor 99% gewijzigd door willempipi op 24-07-2023 23:19 ]

[Caelorum]

Ik neem aan dat je daarna ook doorvraagt over wat er precies is besproken en wat de reden daarvoor is? Op die manier kan je tenminste een fatsoenlijke inhoudelijke discussie starten.

[willempipi]

..

[ Voor 99% gewijzigd door willempipi op 24-07-2023 23:12 ]

[willempipi]

...

[ Voor 109% gewijzigd door willempipi op 24-07-2023 23:12 ]

[Daniel.]

Is het niet een oplossing om een keertje een Proof-of-concept van jou ontwerp te laten tonen zodat hij in Real-Life kan meemaken dat het idee beter is dan zijn idee. Zo kan hij inzien dat het beter is i.p.v. dat het bij woorden blijft?

[willempipi]

.

[ Voor 99% gewijzigd door willempipi op 24-07-2023 23:19 ]

[Daniel.]

willemWS schreef op woensdag 25 maart 2015 @ 09:31:
[...]


Hoe moet ik dat zien? Dat ik mijn versie parallel maak aan zijn versie en daarna ga bewijzen dat het beter werkt. Daar krijg ik geen tijd voor, we hebben teveel te doen.

Jup een werkende testversie in jouw opzicht is dat. Kost inderdaad veel tijd, maar dan heb je echt wel bewijs waar je sterk mee staat.

[ocdaan]

Stel je professioneel op. Doe wat je gevraagd word, daar krijg je immers voor betaald. Je bent geen manager of senior, dus als men je inbreng niet wil gebruiken is dat niet jou probleem. Het heeft geen zin om constant het gevecht aan te gaan. En wie zegt dat je gelijk hebt? Misschien ontbreekt het aan jouw kant aan ervaring (dat kunnen we via dit topic niet bepalen, ik zeg alleen maar )Trek het je niet zo aan, deze situatie heb ik zo vaak gezien/meegemaakt. Nogmaals, je bent professional, doe je werk, geef je mening, word er niet naar geluisterd, prima, jij hebt je best gedaan

Succes!

[Janoz]

Die tijd is er natuurlijk eigenlijk niet. We hebben het hier, heel plat gezegd, niet over een hobby projectje, maar een werk omgeving* waar zo te horen nu al onder hoge druk gewerkt wordt en waar waarschijnlijk elk uur verantwoord moet worden.

Wat je beter kunt doen is, niet een test versie maken, maar een businesscase opstellen. Dat klinkt duur en ingewikkeld, maar is eigenlijk niks meer dan een 'dit moeten we aanpassen en dat gaat zoveel tijd/geld kosten, maar daarmee besparen we dit waardoor het op de lange termijn dit op gaat leveren'.

Schrijf dus gewoon uit wat er zou moeten veranderen, en hoeveel tijd dat gaat kosten. Vervolgens onderbouw je hoeveel sneller een whitelabel dan opgeleverd kan worden. Dat kun je vermenigvuldigen met hoe vaak daadwerkelijk zo'n whitelabel opgeleverd wordt en je weet vanaf wanneer het uit kan.


Maar om even over je collega te beginnen. Ik ken het soort types. Die techneuten die er vanaf dag 0 bij gezeten hebben. Dit soort mensen zien hun product als hun kindje. Kritiek (hoe terecht ook) wordt dan vaak persoonlijk opgevat. Bijkomend nadeel is vervolgens dat ze vaak zelf founder, of heel close met de fouder zijn. Dat maakt het vervolgens nog lastiger omdat hij dan vaak automatisch gesteund wordt door het management.


Stel die businesscase open als ze er niks mee willen ga je gewoon op zoek naar een nieuwe uitdaging.

[emnich]

Waarom maak je geen plan wat je kan presenteren aan het management waarmee je denkt dat je de oplevertijd kan verkorten.

Daarbij kan je een flink aantal zaken aankaarten en kan je van elk issue aangeven hoe je het beter kan maken, wat het kost om te maken en wat het ongeveer oplevert in tijdwinst.

[aZuL2001]

Waarbij je als uitgangspunt nog even de situatie nu met benodigde stappen en tijd kunt beschrijven.
Dan komt jouw suggestie ook in het juiste kader te staan.

Is het enkel nog een kwestie van rekenen voor de beslissers.

[Quadradial]

willemWS schreef op woensdag 25 maart 2015 @ 09:20:
[...]

Of het heel goed is voor mijn gemoedstoestand, tja, ik werd een paar weken geleden al slaand wakker uit een droom over zo'n discussie.

Indien je nachtmerries krijgt over discussies met die collega zou ik 2 dingen aanraden

1: zorg ervoor dat management een besluit neemt hoe het moet gaan werken (ICT faciliteert en adviseert)
2: als je er slecht door gaat slapen en het je leven beïnvloed ga dan direct een andere baan zoeken

[willempipi]

.

[ Voor 115% gewijzigd door willempipi op 24-07-2023 23:18 ]

[Refro]

Een andere optie kan zijn gewoon de stoute schoenen aan te trekken en bewijzen dat het beter kan. Ik ben vaker als eens gewoon begonnen met process/structuur verbeteringen en heb hiermee bewezen dat het echt beter kan.

Als je dit pad bewandelt let dan wel goed op dat dit het huidige proces in ieder geval niet slechter maakt en dat je probeert de verbetering geisoleerd op een test systeem door te voeren.

Voor mij heeft het goed uitgepakt gezien mijn recente promotie naar senior (terwijl er geen plek voor was in de organisatie).

[JBrennan]

Janoz schreef op woensdag 25 maart 2015 @ 09:56:
Die tijd is er natuurlijk eigenlijk niet. We hebben het hier, heel plat gezegd, niet over een hobby projectje, maar een werk omgeving* waar zo te horen nu al onder hoge druk gewerkt wordt en waar waarschijnlijk elk uur verantwoord moet worden.

Wat je beter kunt doen is, niet een test versie maken, maar een businesscase opstellen. Dat klinkt duur en ingewikkeld, maar is eigenlijk niks meer dan een 'dit moeten we aanpassen en dat gaat zoveel tijd/geld kosten, maar daarmee besparen we dit waardoor het op de lange termijn dit op gaat leveren'.

Schrijf dus gewoon uit wat er zou moeten veranderen, en hoeveel tijd dat gaat kosten. Vervolgens onderbouw je hoeveel sneller een whitelabel dan opgeleverd kan worden. Dat kun je vermenigvuldigen met hoe vaak daadwerkelijk zo'n whitelabel opgeleverd wordt en je weet vanaf wanneer het uit kan.

...

Stel die businesscase open als ze er niks mee willen ga je gewoon op zoek naar een nieuwe uitdaging.

Dit dus. Dat is m.i. de enige professionele manier om hier mee om te gaan. Als dat niet werkt zul je idd moeten bepalen of het dan nog het werk voor jou is.

Helaas kan ik geen post upvoten, anders had ik dat gedaan .

[Nukar]

Je verhaal komt over alsof je niet 'dezelfde' taal spreekt als de mensen die de beslissingen nemen. Jij ervaart dit als een probleem, zij blijkbaar (nog) niet.

Dit komt waarschijnlijk omdat zij de 'pijn' niet voelen of niet als pijnlijk ervaren. Je zou jezelf eerst kunnen afvragen of zij jouw probleem wel herkennen en als ze dat al doen of zij het ook als een probleem zien. Pas dan kun je gaan bepalen hoe je hun beeldvorming kunt beïnvloeden.

Over het algemeen werkt praten in risico's en kosten het beste.
Als jij kan aantonen dat de huidige situatie duurder is dan de gewenste situatie dan is management sneller geneigd te luisteren.

Dus doorlooptijd in uren * uurprijs betrokkenen van oplossing A en B tegen elkaar afzetten.
Dat aanvullen met de extra uren * uurprijs voor alle extra beheer tijd.
En indien mogelijk moeilijk meetbare zaken als downtime of gezichtsverlies bij klanten etc. meenemen.

Als men dan nog steeds vind dat het geen probleem is, dan kun je altijd nog verder zoeken en al het geleerde meenemen naar een andere werkgever.

Probeer ook medestanders te vinden. Bijvoorbeeld een tester of business vertegenwoordiger die jouw probleem herkend.

[Dets]

Als je wat wil verbeteren helpt het echt alleen als je aanhaakt bij wat de business wil. Op vakmanschap ga je dit nooit winnen. In de ogen van de "architect" werkt immers alles goed, hoe onhandig het in jouw ogen ook is. Als er van buiten geen eisen (flexibeler, sneller, goedkoper) komen die een andere aanpak vereisen gebeurt er niets. Je zult de business moeten mobiliseren. Zelfs dan heb je nog de kans de dat de "architect" zegt "kan niet", maar je hebt dan in ieder geval een punt voor de juiste discussie.

(In mijn opleiding waren "stakeholder" en "stakeholdermanagement" de sleutel tot de oplossing van alle problemen)

[ Voor 10% gewijzigd door Dets op 25-03-2015 21:28 ]

[WhiteDog]

Er is maar één manier om het management aan je kant te krijgen en dat is tonen dat jouw manier van werken ze uiteindelijk geld zal besparen, liefst op korte termijn.

Jij wil dat zaken kunnen opgeleverd worden met een druk op de knop, je collega wil er X uur tijd insteken.
Hoeveel tijd heb je nodig om dat werk te automatiseren?

Als dat minder is dan X uur maal aantal keer dat dit gebeurt per jaar zou het management je meoten volgen. Je kan ook nog deze argumenten aanbrengen: sneller opleveren aan de klant, minder kans op fouten, jij en je collega's kunnen aan nuttigere taken werken, ...

[Ankona]

Management is vaak (terecht) bang voor wilde plannen, zeker als het om bedrijfskritische materie gaat.

Signaleer een (niet te groot) concreet punt, en maak daar een business case van. Dus geef aan hoe je dit concreet op denkt te lossen, wat het kost maar vooral ook wat het oplevert. Ga niet meteen de hele boel overhoop gooien, maar pak een kleine tastbare verbetering in de richting die jij wenst.
Krijg je hier groen licht voor, dan heb je je kans om je te bewijzen. Ga je op je bek dan weet je dat je je voorlopig gedeisd moet houden, lukt het dan bewijs je je gelijk en bouw je veel credits op.

[T-Forever]

Wie niet wilt luisteren moet maar voelen, laat je collega al die k*tklusjes die voortkomen uit slecht 'design' zelf oplossen, misschien gaat er dan wel een lichtje branden.

[Ankona]

T-Forever schreef op donderdag 26 maart 2015 @ 00:39:
Wie niet wilt luisteren moet maar voelen, laat je collega al die k*tklusjes die voortkomen uit slecht 'design' zelf oplossen, misschien gaat er dan wel een lichtje branden.

Dat is echt de houding waarmee je je eigen exit voorbereid.

Roepen dat dingen slecht zijn is niet moeilijk. Daar zeg je voor het management ook niets nieuws mee, je wekt alleen irritatie op waar niemand op zit te wachten. Roepen dat het beter moet en kan idem.

"Daar heb je weer zo'n eigenwijze jonge hond die het allemaal beter denkt te weten maar waar we concreet niets aan hebben...."

Vandaar mijn eerdere opmerking. Accepteer de situatie zoals die nu is. Daar verdient het bedrijf zijn brood mee en dat werkt. Hoe slecht ook, het werkt. Er zijn zat projecten de volledig mislukt omdat iets dat werkt omgebouwd moest worden tot iets veel beters dat niet werkt. Daar wil het management dus vaak niet aan. Vind je dat iets beter moet, maak daar dan een business case van. Toon concreet aan hoe je het wil verbeteren, wat dat kost en wat het kost om het niet te doen. Heb je dat helder, dan heb je iets waarmee je meestal zo het management meekrijgt.

[chime]

Je kan altijd de tactiek hanteren van: "kampplaats properder achterlaten dan toen je aankwam"

Dus, moet je iets aanpassen => maakt het dan iets beter.
Maar!
Spendeer er niet te veel tijd aan - gewoon kleine verbeteringen: kleine refactoring, wat extra unit testen, beter leesbare variabele/methode namen, ...
Reserveer desnoods max 30min - 1u om iets te verbeteren.

[Ankona]

Dat is altijd een goede instelling, maar daarmee refactor je vooral de stijl van de code, niet de architectuur.

Niets mis met die houding. En ook niets mis met refactoring in baby-steps. Maar verwacht niet dat je daarmee een monolitische applicatie gebouwd volgens het welbekende spaghetti pattern snel ombouwt tot een elegant en testbaar platform met dependency injection.
Bovendien, als anderen ook aan het project werken zullen die met hun lompe laarsen jouw zorgvuldig opgeruimde code weer vervuilen.

[chime]

Om het cru te stellen - is het ombouwen van een legacy, monolitische applicatie vaak nooit interessant.
Kost te veel tijd en moeite.

Iets beter is om nieuwe functionaliteit voor die oude applicatie dan als modules te beschouwen en die er dan relatief proper in te schuiven.
Die modules kan je dan ook proper testen, propere architectuur geven op basis van wat ze moeten kunnen en later ook weer weggooien/vervangen als dat nodig mocht zijn.

Het probleem is natuurlijk om dat verkocht te krijgen.
Beste manier om dat te doen is door gewoon even uit te rekenen wat een change nu kost om door te voeren en hoe vaak deze per jaar gevraagd wordt..
Daarnaast wat het kost om een verbetering door te voeren die de change met 1 druk op de knop uitvoert.

Geld is iets waar het management toch wel naar gaat kijken en is een taal die ze kennen.

Rond duplicate data kan je wat onheilsverhaaltjes gaan rondspuien.
Wat als ...
Als er door fouten inconsistente data ontstaat => is dat dan een bedrijfsrisico of niet?
Als er daar een risico is zie ik management daar nog wel mogelijk stappen gaan ondernemen om dat aan te passen.

Ook vraag ik me af wat men intern doet rond code kwaliteit en opleiding.
Staat men daarvoor open?
Zo ja => laat iedereen clean code lezen.
Desnoods 1 uur inplannen / week om even een bespreking te doen van 1 hoofdstuk. Iedereen leest voor de meeting, in de meeting is er 1 iemand die door het hoofdstuk loopt en zijn samenvatting geeft de andere kunnen daar op ingaan.

Op die manier wordt er wat inzicht gekweekt en krijg je ook discussie.

Refactoring van Martin Fowler lijkt me daarna het 2e boek dat voor jullie wel eens interessant kan zijn


Maar besef:
- mensen houden niet van verandering => dus bij teveel in 1 keer gaan mensen over naar een "hakken in het zand" - modus
- vaak krijg je de reactie: "nu gaat het toch ook"
- management houdt niet van "tijdverspilling", want ja ... developers die wat liggen te lullen die zijn niet aan het werk.

[Logico]

Ik zou beginnen met niet verwachten dat het van het ene op het andere moment veranderd zal gaan worden. Je collega heeft een belangrijke positie binnen het bedrijf verworven en die zullen ze niet afvallen tegenover jou. Je zal de progressie dan ook stapsgewijs moeten zien te bewerkstelligen. Lobbyen werkt dan het beste, zorg dat je medestanders krijgt die ook van zich laten horen (dan ben je ook niet de enige die "zeurt", in de ogen van de tegenstanders).

Als jullie een goede financieel manager/business controller hebben zou je bijvoorbeeld ook met hem kunnen gaan praten, als er iemand geïnteresseerd is in kostenbesparingen zou die het moeten zijn.

Verder kan bijvoorbeeld met een operationeel manager besproken worden wat jij ziet als belemmering van de groeimogelijkheden, als ik de TS zo lees ga je bij het opschalen van je diensten problemen krijgen doordat je dan meer personeel nodig gaat hebben die in die databases aan het werken is om de boel in orde te krijgen voor de oplevering waardoor je uiteindelijk een systeem hebt wat een beetje houtje-touwtje in elkaar zit.