Softwarearkitekter skal smage deres egen medicin

Så nu skal softwarearkitekter rent faktisk prøve deres software for at finde ud af brugeroplevelsen?
Hvad gjorde de før?

Så nu skal softwarearkitekter rent faktisk prøve deres software for at finde ud af brugeroplevelsen?
Hvad gjorde de før?AliasStef (#1)

Ja det er sgu ikke ligefrem nogen nævneværdig nyhed, at en dude mener, at softwarearkitekter skal prøve deres software af. Hvad bliver det næste? Skal spildesignere også prøve deres spil og skal Uwe Boll se sine egne film?

Ja det er sgu ikke ligefrem nogen nævneværdig nyhed, at en dude mener, at softwarearkitekter skal prøve deres software af. Hvad bliver det næste? Skal spildesignere også prøve deres spil og skal Uwe Boll se sine egne film?Theis (#2)

Og skal medicinproducenter smage deres egen medicin?

Ja nu står der jo faktisk at det er deres design de skal prøve.. dvs det design de fastlægger som en koder (som mig) skal implementere... og ja der er faktisk ofte problemer når en arkitekt ikke selv har fingrende i koden også...

Jeg har set problemet af og til....

Det virker som en god ide.

#1: De var sikkert ligeglade og allerede videre til næste projekt.

#2: Nogle gange kunne man godt tro at spil designere ikke havde prøvet deres egne spil. Specielt når det gælder wii shovelware.

Både arkitekter og programmører skulle være med i hele processen.

Jeg har da set flere eksempler på software som ikke virker hensigtsmæssigt i praksis på trods af at det er testet grundigt. En del af disse problemer kunne være undgået hvis udvikleren havde prøvet at sidde i brugerens sted med de faktiske data i stedet for at teste med nogle fiktive data.

udover at sætte dem selv til at bruge deres software, så kan det også være en god ide at sætte dem til at lytte med, når deres firstline support hjælper deres slutbrugere.

arkitekter og programmører, der rent faktisk prøver egen software, laver den ofte så det selv forstår den, hvilket ikke helt er nok, hvis det er software der skal bruges af hr og fru Danmark.

Har set udviklere der fik sig noget af en aha-oplevelse af at sidde et par timer i supporten

Så nu skal softwarearkitekter rent faktisk prøve deres software for at finde ud af brugeroplevelsen?
Hvad gjorde de før?AliasStef (#1)

Haha, det er så lige 33% af de punkter du bider mest mærke i. Jeg tvivler på mange arkitekter rent faktisk har brugt der egen software, så de virkelig kan mærke smerten ved tign der ikke er lavet på den mest optimale måde.

Ingen ide om du rent faktisk selv udvikler, men Frank B mener jeg laver MEGET store systemer i DE.

mvh

Svare vel til, at spildesignere skal prøve deres egne spil? Har dem til tider lidt mistænkt for, at de ikke på nogen måde gør...

Software arkitekter har brug for at opleve udviklernes frustrationer ligesom både arkitekter og udviklere har brug for at møde kunden for at opleve deres frustrationer.

Jeg oplever stort set altid at udviklingsholdet er fuldstændigt afgrænset fra brugerne. De ser aldrig en bruger forsøge at bruge deres produkt og derfor lærer de heller ikke hvad de burde have gjort bedre.

Jeg har til gengæld også siddet i et job hvor jeg havde direkte kontakt med de kunder som skulle bruge softwaren. Resultatet var at softwaren blev meget bedre for kunderne hvilket betød markant gladere kunder.

Som udvikler lærer man meget af at opleve at kunderne ikke kan finde ud af noget som man selv synes er absolut indlysende.

Det har jeg gjort hele tiden, men det er brugerfladen bestemt ikke blevet bedre af.
Hvis det kun var mine krav til funktionalitet der gjaldt så ville vi have tonsvis af CLI-programmer med crazy options, config-filer overalt og noget af det første man lærte ville være at pipe til grep.

Det har jeg gjort hele tiden, men det er brugerfladen bestemt ikke blevet bedre af.
Hvis det kun var mine krav til funktionalitet der gjaldt så ville vi have tonsvis af CLI-programmer med crazy options, config-filer overalt og noget af det første man lærte ville være at pipe til grep.kalleguld (#11)

Brugerfladen er hele programmet, fuck det bagved, det ser brugeren alligevel ikke.

Kan programmet ikke bruges, sælger det ikke.

Selvfølgelig ikke sagt at der ikke skal være en god struktur bag, så det nemmere kan udvides osv.

#12
Jeg giver dig helt ret, hvad i alverden lavere udviklere? Hvorfor i al verden gør de kun halvdelen af deres arbejde, nemlig at udvikle et program, men undersøger ikke forudsætningerne for det de skal udvikle, de udvikler bare.

Det er lidt som at gå ind i en taxa og sige kør! og tror at man kommer hjem.

Når man sidder som bruger, så undre man sig tit over, om de rent faktisk overhovedet har koblet brugernes behov til programmernes funktionalitet.

Selv It afdelinger har ofte ikke brugerne i tankerne når de køber software.

Scanjours Captia er et af de helt store og gode eksempler på det. Jeg hørt flere steder fra it afdelinger, at hvis de havde undersøgt brugernes behov, så var valget aldrig faldet på captia. Det er bare for dyrt at skifte.

... Og jeg må indrømme, jeg tror aldrig, at jeg har mødt en bruger, som synes at captia er et godt stykke software, og passer til behovene. Jo overordnet set på makroniveau, men på mikroniveau er det en skandale.

Det er også kun udviklere som synes, at browserafviklede applikationer er gode. Brugerne hader dem stort set altid. Det forunderlige er, at it afdelinger og udviklere ikke kan forstå hvor crappy webapplikationer er og hvor forhadte de hos brugerne.

Man ikke vælge et stykke software uden en brugerundersøgelse, selv cheferne har meget sjældent et tilstrækkeligt indblik på mikroniveau til at kunne udtalele sig fornuftigt.

Bruger undersøgelser i de indledende facer er helt essentielle for at software til f.eks. offentlige institutioner bliver en succes. Efter en række kvalitative interviews kan der jo opstilles kvantiative spørgeskemaer. It branchen skal forstå, at de skal have sociologer , økonomer eller statskundskaber eller andre med forstand på at undersøge behov til at udføre den del af opgaven.

Det kræver så bare, at datamatikere og dataloger erkænder at de ikke er tankelæsere :-D

Det er også kun udviklere som synes, at browserafviklede applikationer er gode. Brugerne hader dem stort set altid. Det forunderlige er, at it afdelinger og udviklere ikke kan forstå hvor crappy webapplikationer er og hvor forhadte de hos brugerne.-N- (#13)

Forkert !

Jeg har også arbejdet på et projekt hvor vi har tabt flere kunder fordi vi havde en Windows applikation i stedet for en web applikation.

Jeg hader selv web applikationer, men det er altså ikke alle brugere som har det på samme måde.

#14 Nej det er rigtigt, og jeg vil medgive, at netop det at en applikation afvikles af browseren kan skabe tryghed.

Men det er vel også væsentligt nemmere at servicere en applikation som afvikles i browseren, i den forstand at der er færre ting som kan påvirke stabiliteten?

En browser er heller ikke bare et fælles miljø som er upåvirkeligt. Webbrowsere bliver skiftet ud ret ofte og du er nødt til at være kompatibel med alle de browsere som kunden kan finde på at køre.

Hvis du er så heldig at det inkluderer IE6 så gør det ikke opgaven lettere.

Jeg vil personligt foretrække at vedligeholde en Windows applikation, men det er en smagssag.

men Frank B mener jeg laver MEGET store systemer i DE.syska (#8)

Siemens er en meget stor biks.

Og software er uden tvivl en vigtig del af deres produkter idag.

Men jeg ved ikke med "store".

http://www.linkedin.com/pub/frank-buschmann/6/112/519

Key activity area is the Industry sector, with a focus on engineering and runtime systems for DCS, SCADA, and PLC in various domains, such as rail, postal, building, factory and process automation.

Det lyder meget "småt" i mine ører.

:-)

(embedded systemer med realtime requirements og begrænsede hardware ressourcer er dog typiske mere vanskelige end de store web/app/database servere)

Så nu skal softwarearkitekter rent faktisk prøve deres software for at finde ud af brugeroplevelsen?AliasStef (#1)

Ja det er sgu ikke ligefrem nogen nævneværdig nyhed, at en dude mener, at softwarearkitekter skal prøve deres software af.Theis (#2)

Artiklen drejer sig om at software arkitekter skal sætte sig i udviklens sted og ikke i slutbrugerens sted.

Det giver også mening da output fra software arkitekter er input til udviklere og ikke slutbrugere.

#substans

Det er jo indlysende rigtigt.

Kode er ikke en arkitektonisk artifakt (godt eksempel på at noget der lyder rimeligt på engelsk lyder rædselsfuldt på dansk) så det er ikke arkitekt arbejde at producere kode.

Men ikke desto mindre er det godt hvis en software arkitekt bruger 5-10% af sin tid på udvikling.

Ellers er der store risiko for at arkitektens opfattelse af softwaren og softwaren i den virkelige verden bevæger sig i hver sin retning.

En software arkitekt skal:
- vælge teknologi (programmerings sprog, frameworks etc.)
- fastlægge tiers og protokoller mellem dem
- fastlægge layers og interfaces mellem dem
- fastlægge de overordnede data strukturer
- fastlægge de overordnede execution flows

At vælge teknologi uden selv at have prøvet at bruge dem er særdeles risikabelt.

Det er meget svært at vurdere om en opdeling af applikationen giver mening uden at have set på hvordan koden kommer til at se ud i praksis.

Og at antage at udviklerne altid laver koden så den matcher diverse class og sequence diagrams er naivt.

Så software arkitekten bør:
- være med i POC arbejde for nye teknologier eller nye versioner af allerede brugte teknologier
- deltage i alle code reviews
- en gang om året lave noget regulært udviklings arbejde (kan godt bare være simpel bug fixing)
- deltage i alle større troubleshooting'er

#fortsat

Hvis jeg må citere mig selv (!):

http://www.eksperten.dk/guide/1190

Application Architect/Software Architect

Job:
- skal forstå et eller flere systemer til bunds
- er ansvarlig for opdelingen i tiers og layers
- er ansvarlig for valg af teknologi (programmerings sprog, frameworks,
værktøjer)

Kendetegn for en god:
- kan finde den bedste løsning på ethvert problem med systemet

Kendetegn for en dårlig:
- vedligeholder et større antal diagrammer som intet har med den faktiske
software at gøre

Det er også kun udviklere som synes, at browserafviklede applikationer er gode. Brugerne hader dem stort set altid. Det forunderlige er, at it afdelinger og udviklere ikke kan forstå hvor crappy webapplikationer er og hvor forhadte de hos brugerne.-N- (#13)

Det er nok kun IT folk der hader desktop apps p.g.a. alt det junk man får installeret på sin PC (for Windows brugere specielt det som ender op i registry).

Jeg tror dog primært at slutbrugerne hader gammeldags web apps. Slutbrugere synes ikke at have noget imod diverse Google og FaceBook web sites.

Og der er faktisk også enkelte fordele for slutbrugere ved web apps - mulighederne for SSO er langt bedre end ved desktop apps.

Og ledelsen kan godt lide de lavere deployment og test omkostninger ved web apps.

Så jeg synes at billedet er lidt mere nuanceret end du giver udtryk for.

#21 Verdenen er altid mere nuanceret end en mands gengivelse af den :-P

Jo, jeg skrev det lidt bombastisk fordi nogle af de første indlæg tilsyneladende ikke kunne se formålet med at sidde i den anden ende :-D

Jeg giver de helt ret, web apps ser fine ud på bund linjen, men min egen holdning er, at pengene måske bliver tjent hjem på tilfredse brugere, som ikke tænker "åh nej" når de skal bruge det, som det f.eks. er tilfældet for langt mange captia brugere :-D

Den effekt er selvfølgelig ikke nem at dokumentere, men generelt er penge brugt på tilfredse medarbejdere, god givet ud.

En helt anden ting, jeg har aldrig mødt andre en nørder som bruger google docs. De gange hvor nogle har sendt ud i en gruppe, så er det kun nørderne som har læst det. Det er selvfølgelig kun egne erfaringer.

Jeg kan næppe forstø at Frank Buschmann har behov for at klargøre dette.
Det samme gælder jo dataloger og softwareingeniørerne; at vi ligeledes skal forstå brugeren, når det gælder design af vores systemer.

Jeg er ret sikker på at arkitekterne ligeledes får undervisning i at afprøve deres design og at de ligeledes får undervisning omkring byggestenene indenfor system udvikling eftersom de er softwarearkitekter

Hvis softwarearkitekterne ikke er klar over disse ting, vil jeg mene at man skulle vurdere om deres uddannelse mangler et kursus til at dække dette omfattende og vigtige, men ret enkelte forståelse af software udvikling.

#23

Der er ikke alt som kan læres som teori på et kursus.

Lige netop dette her tror jeg ikke meget på som et kursus.

#24
Jeg tror som sagt også at de allerede får undervisning som der gør dem vidne om at de skal lære af deres egne design. Min pointe er også, at jeg ikke kan se hvorfor man gør så stort et nummer ud af det, når det indenfor design verden siger sig selv.

Ang. teorien, så er det jo en hjælpende hånd til at opdage steder med plads til forbedringer. Der kommer aldrig et perfekt design, og det kræver også erfaring at lave et godt design.

#24
Jeg tror som sagt også at de allerede får undervisning som der gør dem vidne om at de skal lære af deres egne design. Min pointe er også, at jeg ikke kan se hvorfor man gør så stort et nummer ud af det, når det indenfor design verden siger sig selv.

Ang. teorien, så er det jo en hjælpende hånd til at opdage steder med plads til forbedringer. Der kommer aldrig et perfekt design, og det kræver også erfaring at lave et godt design.eliasr (#25)

Der bliver jo netop gjort et så stort nummer ud af det fordi det netop er et problem. Det er jo ikke bare for sjov han siger de ting han gør.

#25

Undervisning iden slags er stort set værdiløs. Det kræver erfaring med virkelig software.

Og det er naturligvis relevant at bringe det på bane, når det er et problem ude i den virkelige verden.