Jeg tror der findes eksempler på at udviklere bliver presset til at springe over hvor gærdet er lavest.
Hvis en overskrift skal være provokerende - så er det lykkedes :-)
Men et team sammensat af udviklertyper med den rette sammensætning - kan yde mere en summen af enkeltmedlemmerne.
Denne "merværdi" kan optimeres ved at teamet kender hinandens styrker og svagheder og supplerer hinanden.
Tilsvarende mindskes "merværdien" jo mere hver enkelte...
1:
Jeg har ikke næstuderet MUMPS (hvilket 99,9999% af udviklerne i denne verden heller ikke har) men ud fra et hurtigt kig på sproget så synes det ikke specielt egnet til noget specifikt domæne. Men det var sikkert ret moderne i 1966.
2:
Relationsdataser er meget udbredt og særdeles velegnet ti...
Sundhedsplatformen er rent IT teknologisk så afvigende fra de sidste 30 års "best practice" at den alene ud fra en IT-håndværksmæssig vurdering bør diskvalificeres.
Herunder:
- Sundhedsplatformen er kodet i et urgammelt niche programmeringssprog https://en.wikipedia.org/wiki/MUMPS
-...
Især synes jeg at læse at gevistrealisering bedst opstår i det lange stabile samarbejde. Jeg hæfter mig også ved at "fastpris er gift for bevinstrealisering"
Jeg kunne ikke være mere enig.
Så hvis kunden ønsker at leverandøren skal tænke business Casen ind i leverancen - så skal det være en af de parametre som leverancen måles på.
Herudover så gætter jeg på at mange Business Cases udarbejdes ud fra den antagelse at projektet/leverancen er et Level 1 kaos. Og at det er i mange tilfæ...
Jeg har netop deltaget i "IDA Ledelse 2018" og hørt en tidligere programchef for Sundhedsplatformen forklare hvorfor det faktisk er en succes. Og det må være klart at implementering af et fælles IT system i en så kompleks verden ikke er nemt - for nu at sige det på jydsk. Og det er...
Det meget spændende spørgsmål er hvordan et sådant fornuftigt project er kommet igennem et EU-udbud - uden at have form af en traditionel vandfaldmodel.
Hvis Skat.dk kunne få en fornuftig projektmodel gennem et EU udbud - så kan andre vel også?
Opfattelser i samfundet ændrer sig langsomt. Det er alt, alt for tidligt at drage konklusioner. Der skal meget mere tid, vedholdende viderearbejde og håndhævelse til- før man kan forvente at gode initiativer som GDPR fører til øget tillid.
Tillid tager som bekendt lang tid at opbygge.
Kunne det være interessant at få de tekniske rådgivere i udbudssagen til at forsvare eller forklare deres oprindelige anbefaling (af Sundhedsplatformen). For man vægrer sig jo ved at tro at ansvarlige og sikkert begavede konsulenter/eksperter kan have anbefalet noget med så mange åbenlyse og let...
Så er konklusionen at et valg bedst afvikles med lidt analog teknologi. Nærmere (eller snarere resumeret) argumentation findes på https://www.linkedin.com/pulse/analog-information-technology-needed-demo...
Igen og igen kommer der forskellige, men samstemmende vinkler på det grundlæggende problem ved den nuværende metodik omkring store IT projekter (ofte i det offentlige).
Denne her er nok mere solidt funderet på erfaringer end min egen mere teoretiske analyse på https://www.linkedin.com/pulse/publi...
Udsagnet (at time to market ikke betyder noget) skal selvfølgelig læses i lyset af om man vælger det hurtigste programmeringssprog (at udvikle i) eller det mest langtidsholdbare og vedligeholdelsesvenlige :-)
Jeg tror det bliver svært at finde offentlige IT skandaler hvor programmeringshastighed ...
Udsagnet "Mere eller mindre uændret" skal ses fra helikopterperspektivet.
Dine detaljeringer - som jeg er enig i - understreger at det samlede ressourceforbrug i en appplikations livslængde og dermed vedligeholdelsesvenligheden (i bredeste forstand) er langt vigtigere end om der er en...
Uden at forholde sig til de finere detaljer mellem Groovy og Java vil jeg påstå at det er meget vigtigt at vælge en teknologi som passer til applikationens formodede livslængde. I dette tilfælde er der tale om en funktionalitet som må formodes at skulle virke mere eller mindre uændret i mange år ...
Når man ved hvor meget det belaster organisationen - og dermed hvor omkostningstungt det i virkeligheden er, at udskifte centrale IT-systemer - så må man håbe at Systematic evner og især får lov til at levere deres system til regionen meget, meget langt ud i fremtiden.
Historien om EFI er langt hen ad vejen en illustration af de centrale problemer der er i den gængse offentlige udbudsmodel. Særligt kompleksiteten har været for stor. Se https://www.linkedin.com/pulse/public-scandals-founded-during-contract-p...
Der i praksis fungerer til batchkorsler og avancerede søgninger hvori der skal joines med organisationens øvrige forretningsinformationer.
Kopiregistre er den eneste arkitektur der giver mulighed for integration dybt nede i databasen. Der er simpelthen ikke nogen RDMS databaseoptimisere som virke...
Kommentarer
Doven eller presset
Den perfekte udviklertype findes ikke
Re: Sundhedsplatformen er IT teknisk meget sølle
Sundhedsplatformen er IT teknisk meget sølle
God artikel med flere gode pointer
Leverandøren forsøger at levere det som kunden beder om
Den strategiske fejltagelse vil ikke blive belyst
Hvordan er dette fornuftige projekt igennem et EU-udbud?
Det er alt for tidligt at drage konklusioner
Af akademisk interesse
Helt i tråd med artiklen
Uanset hvordan det vendes og drejes
En stemmeseddel skal være lavet af papir
Store IT projekter er ikke en stangvare
Re: Man bør vælge teknologi under hensyn til forventet livs...
Re: Man bør vælge teknologi under hensyn til forventet livs...
Man bør vælge teknologi under hensyn til forventet livslængde
Med håb om stabilitet
En planlagt ulykke
Kopiregistre er den ENESTE arkitektur